Национальный стандарт республики казахстан


Введение журнала безопасности



страница32/33
Дата20.11.2016
Размер4.62 Mb.
Просмотров7256
Скачиваний0
1   ...   25   26   27   28   29   30   31   32   33


20.6 Введение журнала безопасности
Точность метки времени и целостность записей в журнале зависят от точности и целостности используемого времени для определения.. Точные метки времени важны для поиска неисправностей, анализа, урегулирования споров и доказательства ко времени сделок. В сущности, отлаживая, безопасность, аудит и идентификация основаны на основе событий эти соображения безопасности зависят от синхронизации времени.

В то время как определение точности и целостности хронометрирования не в рамках этого международного стандарта, чтобы продемонстрировать, что метки времени регистрации доверия, метки времени должны быть прослеживаемыми к стандартному времени, и нужно продемонстрировать, что системное время не может быть произвольно изменено.


21 Уведомление очереди
Система хранения облака может произвольно осуществить функциональность уведомления. Внедрение уведомления обозначено присутствием хранения облако возможности всей системы к уведомлению и требует поддержки очередей CDMI.

Уведомления очереди позволяют клиентам CDMI эффективно обнаруживать, какие изменения произошли с системой. Поскольку данные очереди постоянные, никакая система не сохраняется пользователем. Если различные очереди уведомления используются для различных клиентов, то каждый клиент действует независимо от других (например, приложение для управления хранением может использовать очередь уведомления, чтобы держать ее базу данных в курсе, не имея необходимость делать полные просмотры контейнера, чтобы обнаружить, какие объекты данных были добавлены, изменены или удалены).

Когда клиент хочет получить уведомления, это может сначала проверить, способна ли система к предоставлению уведомлений, проверяя на присутствие cdmi_notification способности в возможностях контейнера корня. Если эта способность не будет присутствовать, то создавание уведомления очереди должно быть успешным, но никакие уведомления не должны быть поставлены в очередь уведомления

Чтобы создать очередь уведомления, клиент создает регулярную очередь CDMI и добавляет метаданные, приказывающие системе хранения рассматривать очередь как очередь уведомления. Эти добавленные метаданные также инструктируют систему о том, какие типы уведомлений должны быть произведены и информация должна быть включена с каждым уведомлением.

После того, как очередь уведомления создана, все последующие события соответствия после того, как время создания очереди должно привести к результатам уведомления, поставленным в очередь в очередь. CDMI не передает под мандат определенного заказа событий, и клиенты должны быть в состоянии обращаться с событиями, которые прибывают не в порядке.

Создавая очередь уведомления, метаданные, описанные в Таблице 122, должны быть соблюдены. Попытки изменить метаданные в этом столбце должны привести к коду состояния HTTP 403 Запрета. После того, как очередь уведомления была создана, за исключением cdmi_queue_type, пункты метаданных в этом столе не могут быть изменены. cdmi_queue_type может только быть удален, указав к системе, что очередь уведомления больше не должна получать уведомления и должна рассматриваться как регулярный объект очереди CDMI

Таблица 122 - Required Metadata for a Notification Queue (Sheet 1 of 3)

Таблица 122 Необходимые метаданные для очереди уведомлений (Стр 1 из 3),



Метаданные названия

Тип

Описание

Требования

cdmi_queue_type

JSON строка

Тип очереди указывает, как система хранения облака должна управлять объектом очереди. Тип cdmi_notification_queue определен для очередей уведомления.

Обязательное

cdmi_notification_events

JSON строка JSON массив

Содержит множество JSON, которое указывает, какие события производят уведомления. Определенные ценности:

• cdmi_create_processing - Уведомления произведены, когда новый объект создан, но находится все еще в статусе завершения обработки.

• cdmi_create_complete - Уведомления произведены, когда новый объект немедленно создан или когда новый объект в процессе того чего созда переходы от статуса завершения "обработки".• cdmi_read - Уведомления произведены, когда объект прочитан.• cdmi_modify_processing - Уведомления произведены, когда существующий объект изменен, но находится все еще в статусе завершения обработки.


Обязательное

Таблица 122 Необходимыеметаданные для очереди уведомлений (Стр 2 из 3),



Метаданные названия

Тип

Описание

Требования

cdmi_queue_type




JSON строка

• cdmi_modify_complete - Уведомления произведены, когда существующий объект изменен и находится в полном статусе завершения. Это уведомление также произведено когда существующий объект, измененный переходы от "Обработки", чтобы "Закончить".

• cdmi_rename - Уведомления произведены, когда объект переименован как часть операции по сообщению запроса движения.

• cdmi_copy - Уведомления произведены, forthe недавно создал скопированный объект, когда копия закончена.

• cdmi_reference - Уведомления произведены, когда ссылка создана.

• cdmi_delete - Уведомления произведены, когда объект удален.

• cdmi_export - Уведомления произведены, когда контейнер экспортируется.

• cdmi_snapshot - Уведомления произведены, когда контейнер - snapshotted.

• <определенные события конструктора> Клиенты могут включать желаемые типы уведомления событий в cdmi_notification_events JSON множество. Если все события уведомлений будут желаемы, то пустое множество JSON должно использоваться.



Обязательное

cdmi_scope_specification

JSON строка JSON массив

Спецификация объема определяет набор объектов, на которых операции вызывают поколение уведомлений. Если уведомления желаемы для всех объектов, включают пустое множество JSON.

См. Пункт 18 для того, как построить спецификацию объема.



Обязательное

Таблица 122 Необходимыеметаданные для очереди уведомлений (Стр 3 из 3),



Метаданные названия

Тип

Описание

Требования

cdmi_results_

specification



JSON строка

Содержит области JSON, которые будут возвращены для каждого объекта, который соответствует спецификации объема уведомления. См. Пункт 19 для того, как построить спецификацию результатов.

В дополнение к областям, определенным в Пункте 19, для уведомлений, определены четыре дополнительных области:

• cdmi_event - Указывает на событие, как определено в cdmi_notification_events области, которая вызвала уведомление;

• cdmi_event_result - Указывает на результат статуса события, которое вызвало уведомление. Статус совпадает со статусом, который был возвращен по запросу HTTP, т.е., 200 хорошо, 404 Не Найденный, и т.д.;

• cdmi_event_time - Указывает время события, которое вызвало уведомление. Время будет отформатировано во время ISO 8601 (см. 5.14 и ISO 8601:2004); и

• cdmi_event_user-Указывает на руководителя (имя ACL) пользователя, который вызвал событие, которое вызвало уведомление.

Если система вызвала событие, имя оставят как пустая последовательность.


Обязательное

ПРИМЕР 1 метаданные, связанные с очередью уведомления, следующие:

{

"metadata" : {



"cdmi_queue_type" : "cdmi_notification_queue",

"cdmi_notification_events" : [

"cdmi_create_complete",

"cdmi_read",

"cdmi_modify_complete",

"cdmi_delete"

],

"cdmi_scope_specification" : [



{

"domainURI" : "== /cdmi_domains/MyDomain/",

"parentURI" : "starts /sandbox",

"metadata" : {

"cdmi_size" : ">+100000"

}


}

],


"cdmi_results_specification" : {

"cdmi_event" : "",

"cdmi_event_result" : "",

"cdmi_event_time" : "",

"objectID" : "",

"metadata" : {

"cdmi_size" : ""

}

}



}

}

Когда результаты уведомления хранятся в очереди уведомлений, каждый в очередь значение должно состоять из объекта JSON MIME-типа "приложения / JSON". Этот объект JSON содержит указанные значения, требуемые в cdmi_results_specification метаданных очереди уведомлений.



ПРИМЕР 2 Результат уведомления В КАЧЕСТВЕ объекта JSON следующие:

{


"cdmi_event" : "cdmi_read",

"cdmi_event_result" : "200 OK",

"cdmi_event_time" : "2010-11-15T13:12:52.342324Z",

"objectID" : "00007E7F0010EB9092B29F6CD6AD6824",

"metadata" : {

"cdmi_size" : "108263"

}

}

Объекты должны только быть включены в результаты уведомления, если пользователь, который создал очередь уведомления, будет в состоянии прочитать соответствующий объект.



Если очередь уведомления была создана администратором, то все соответствие возражает, что администратору разрешают читать, включены в результаты. Если очередь уведомления была создана пользователем "jdoe", то только соответствие объектам, которые "jdoe" позволяют прочитать, включено в результаты.

Таблица 123 описывает созданные из системы метаданные, которые предоставляют подробную информацию о статусе очереди уведомления.

Таблица 123 Уведомление о статусе метаданных

Метаданные названия

Тип

Описание

Требования

cdmi_notification_status

JSON строка

Последовательность, указывающая на государство очереди уведомления. Определенные ценности:

• Обработка - Указывает, что очередь уведомления просматривает для результатов;

• остановленный - Указывает, что новые уведомления больше не будут ставиться в очередь;

• ток - Указывает, что очередь уведомления содержала все уведомления, которые могут быть найдены в это время; и

• Ошибка - Указывает, что метаданные очереди уведомления не действительны, или с другими ошибками столкнулись, который препятствовал тому, чтобы сообщения уведомления были поставлены в очередь. Произвольный определенный продавцами текст может следовать за последовательностью "Ошибка. Если этот пункт метаданных не существует, то уведомления еще не начали быть поставленными в очередь.


Обязательное


22. Запрос очереди
22.1 Обзор
Система хранения облака может произвольно осуществить метаданные и/или полнотекстовую функциональность вопроса. Внедрение вопроса обозначено присутствием хранения облака возможности всей системы к вопросу и требует поддержки очередей CDMI.

Очереди вопроса позволяют клиентам CDMI эффективно обнаруживать, какое содержание соответствует данному набору критериев вопроса метаданных или критериев поиска полного содержания. Клиенты создают или обновляют очередь вопроса, определяя метаданные, которые определяют соответствующие критерии (известный как объем вопроса), наряду с тем, какие результаты должны быть возвращены для соответствия объектам (известный как результаты вопроса). Предложение CDMI должно тогда выполнить вопрос, используя содержание, существующее в то время, когда вопрос обрабатывается, храня результаты вопроса в очереди вопроса. Поскольку результаты вопроса найдены, они добавлены к очереди, и когда вопрос полон, cdmi_query_status метаданные очереди изменены, чтобы указать, что вопрос закончил. Любые объекты соответствия, созданные или измененные, в то время как вопрос выполняется, могут или не могут быть включены в результаты вопроса (например, в результате возможной последовательности).

Когда клиент хочет выполнить вопросы, это может сначала проверить, способна ли система к обеспечению функциональности вопроса, проверяя на присутствие cdmi_query способности в возможностях контейнера корня. Если эта способность не будет присутствовать, то создавание очереди вопроса должно быть успешным, но никакие результаты вопроса не должны быть поставлены в очередь вопроса

Создавая очередь вопроса, метаданные, описанные в Таблице 124, должны быть соблюдены. Попытки изменить метаданные в этом столе должны привести к коду состояния HTTP 403 Запретов. После того, как очередь вопроса была создана, за исключением cdmi_queue_type, пункты метаданных в этом столе не могут быть изменены. Если ценность cdmi_queue_type изменена от "cdmi_query_queue", это изменение указывает к системе, что незавершенный вопрос должен быть остановлен, очередь вопроса больше не должна получать результаты вопроса, и очередь вопроса нужно рассматривать как регулярный объект очереди CDMI. Чтобы начать новый вопрос с существующей очереди, ценность cdmi_queue_type должна быть изменена назад на "cdmi_query_queue". Этот международный стандарт не определяет механизм, чтобы сделать паузу бегущий вопрос или возобновить остановленный вопрос


Таблица 124 Необходимые метаданные для очереди запросов

Метаданные названия

Тип

Описание

Требования

cdmi_queue_type

JSON строка

Тип очереди указывает, как система хранения облака должна управлять объектом очереди. Тип cdmi_query_queue определен для очередей вопроса.

Обязательное

cdmi_scope_

specification



JSON строка

Спецификация объема определяет, какие объекты включены в результаты вопроса. Это эквивалентно "ГДЕ" пункт на подобных SQL языках. Чтобы подвергнуть сомнению все объекты, определите пустое множество JSON. См. Пункт 18 для того, как построить спецификацию объема.

Обязательное

cdmi_results_

specification



JSON строка

Содержит области JSON, которые будут возвращены для каждого объекта, который соответствует вопросу. Это эквивалентно "ИЗБРАННОМУ" пункту на подобных SQL языках. См. Пункт 19 для того, как построить спецификацию результатов.

Обязательное

ПРИМЕР 1 пример метаданных, связанных с очередью вопроса:

{

"metadata" : {



"cdmi_queue_type" : "cdmi_query_queue",

"cdmi_scope_specification" : [

{

"domainURI" : "== /cdmi_domains/MyDomain/",



"parentURI" : "starts /sandbox",

"metadata" : {

"cdmi_size" : "#> 100000"

}


}

],


"cdmi_results_specification" : {

"objectID" : "",

"metadata" : {

"cdmi_size" : ""

}

}

}



}

Когда результаты хранятся в очереди запросов, каждый в очередь значение должно состоять из объекта JSON MIME-типа "приложения / JSON". Этот объект JSON содержит указанные значения, требуемые в cdmi_results_specification метаданных очереди запросов.

ПРИМЕР 2 пример результата вопроса объект JSON:

{


"objectID" : "00007E7F0010EB9092B29F6CD6AD6824",

"metadata" : {

"cdmi_size" : "108263"

}

}



Таблица 125 описывает созданные из системы метаданные, которые предоставляют подробную информацию о статусе очереди вопроса.
Таблица 125 Запрос состояния метаданных

Метаданные названия

Тип

Описание

Требования

cdmi_query_

status


JSON строка

Когда существующий, этот пункт метаданных указывает на государство очереди вопроса. Определенные ценности:

• Обработка - Указывает, что очередь вопроса просматривает для результатов;

• остановленный - Указывает, что новые результаты вопроса больше не будут ставиться в очередь;

• ток - Указывает, что очередь вопроса содержала все результаты вопроса, которые могут быть найдены в это время; и

• Ошибка - Указывает, что метаданные очереди вопроса не были действительны, или с другими ошибками столкнулись, который предотвратил все следствия вопроса того, чтобы быть поставленным в очередь. Произвольный определенный продавцами текст может следовать за последовательностью "Ошибка".


Обязательное

Объекты должны быть включены в результаты вопроса, если пользователь, который создал очередь вопроса, будет в состоянии прочитать соответствующие объекты или метаданные. Например, если администратор создал очередь вопроса, то все соответствие возражает, что администратору разрешают читать, включены в результаты. Если пользователь "jdoe" создал очередь вопроса, то только соответствие объектам, которые "jdoe" позволяют прочитать, включено в результаты.
22.2 Расширение запроса CDMI
Конструктор сервера CDMI может расширить вопрос CDMI, добавив определенные для продавца выражения соответствия. Когда конструктор добавит определенные для продавца поля метаданных, эти области должны быть подвергнуты сомнению, используя стандартную функциональность очереди вопроса.

Конструктор сервера CDMI может расширить вопрос CDMI, позволив создание определенных для продавца очередей вопроса с типом кроме cdmi_query_queue.



Приложение A

(нормативное)

Транспортная безопасность
А.1 Введение
Для большинства внедрений CDMI гипертекстовый Протокол передачи (HTTP) является основным коммуникационным протоколом, используемый для передачи сообщения CDMI. Данное приложение определяет детали, связанные с обеспечением основного транспорта.

А.2 Общие требования для внедренияППГ (HyperTextTransferProtocol- Протокол Передачи Гипертекста (ППГ)


Требования безопасности ППГ относятся и к серверам CDMI и к пользователям. Пользователь CDMI должен выполнять все требования безопасности ППГ. Следующие общие требования безопасности ППГ.

Осуществление базовой аутентификации ППГ или идентификация обзора.

Для минимизации пользовательской личности, такие как пароль, внедрение, необходимо использовать базовую аутентификацию ППГ вместе с БТУ.

Пользовательская личность и мандат, используемый с одним типом идентификации ППГ (т.е., основные или обзор), не должны впоследствии использоваться с другим типом идентификации ППГ. Во избежание угрозы целостности схемы, определены методы безопасности избегают повторного использования идентичности и информации о мандате через схемы различных преимуществ.

TLS 1.0 осуществляется с CDMI, более актуальная версия БТУ (например, v1.1 и v1.2) часто используется. Использование БТУ с CDMI необходимо для сохранения данных.

Применяются следующие требования ППГ по БТУ (HTTPS):

Поддерживаемые следующие шифры гарантирует минимальный уровень безопасности и совместимости между внедрениями:


  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (mandatory for TLS 1.0),

  • TLS_RSA_WITH_AES_128_CBC_SHA (mandatory for TLS 1.1/1.2), and

  • TLS_RSA_WITH_NULL_SHA (for TLS without encryption).

Примечание: Конструкторы включают дополнительные номера люкс шифра, не гарантируют совместимость.

Для общения пользователей и серверов, используется последовательный подход к безопасности. Формируемые пользователь-серверы могут не общаться, если полагаться на 80 порт и порт 443. Пользователи, не соединяющиеся с сервером CDMI через ППГ по БТУ на порту TCP 443, должны повторить с ППГ на порту TCP 80.

В данной ситуации пользователи должны соблюдать следующие направления.

— Замена свидетельства, включая свидетельство корня CA, используемые пользователями.

— форматы свидетельства PKCS#12 должны поддерживаться с –закодированным DERX.509, на базе 64 правил кодирования X.509,

— Списки Аннулирования свидетельства поддерживаются в DER-закодированном X.509 и основе 64 правил кодирования X.509.


А.3 Основная Безопасность HTTP (HyperTextTransferProtocol- Протокол Передачи Гипертекста (ППГ)
HTTP (ППГ) - обязательный транспортный механизм для данной версии CDMI. Важно отметить, что ППГ, отдельно, не предполагает защиту конфиденциальности или защиту целостности.

Пользователи CDMI ответственны за инициирование пользовательской идентификации для каждого сервера CDMI.

IETF ссылка 2616 и IETF ссылка 2617 определяют требования для идентификации ППГ, начинающиеся с запросом пользователя ППГ. Если запрос пользователя не включает поле заголовка "Разрешения", идентификация требуется, где сервер отвечает 401 Несанкционированным кодом состояния, и WWW - Подтверждает подлинность линии заголовка. Пользователь ППГ отвечает соответствующей линией заголовка «Разрешения» в последующем запросе. Формат WWW - Подтверждает подлинность, и линии заголовка «Разрешения» варьируется в зависимости от типа требуемой идентификации, базовая аутентификация или идентификация обзора. Если идентификация будет успешна, то сервер ППГ отвечает кодом состояния 200.

Базовая аутентификация включает отправку имени пользователя и пароля в ясном, и это должно только использоваться в безопасной сети или вместе с механизмом, который гарантирует конфиденциальность, такую как БТУ. (См. 4). Идентификация обзора посылает безопасный обзор имени пользователя и пароля (и другая информация включая стоимость данного случая), так, чтобы пароль не был показан. 401 Несанкционированный ответ не должен включать выбор идентификации.

Идентификация пользователя к серверу CDMI основана на службе проверки подлинности (местный и/или внешний). Отличающиеся схемы идентификации могут быть поддержаны, включая основанную на хозяине идентификацию, Kerberos, PKI или другой; служба проверки подлинности отсутствует в объеме этого международного стандарта.


Каталог: sites -> default -> files
files -> Методические рекомендации по проведению Дня Знаний, посвященного Году кино в РФ
files -> Блестящие будущие возможности в сфере икт для нового поколения женщин
files -> Ларцева А. 1 Перевод имен собственных на примере книги ховарда рейнголда
files -> Занятие №18 Здравствуйте, участники программ личностного развития для детей!
files -> Программа кружка «Юный журналист»
files -> Шелакина А. А. Студентка 2 курса атп 921 ппк сгту имени Гагарина Ю. А
files -> Культурного и природного наследия имени д. С. Лихачева
files -> Участники регионального отборочного Чемпионата профессионального мастерства по методике WorldSkills «WorldSkills Russia Иркутск 2016» по компетенции: 21 PlasteringandDrywallSystems – Сухое строительство и штукатурные работы 25 27
files -> Семинар «использование квест- технологии в обучении английскому языку»


Поделитесь с Вашими друзьями:
1   ...   25   26   27   28   29   30   31   32   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал