ГОСТ Р ИСО/МЭК 17826-2015
Т а б л и ц а 121- Метаданные статуса ведения журналов событий
Имя метаданныхТип
Описание
Требование
cdmi_togging_ Строка
Строка, показывающая состояние ведения журналов событий.
statusJSON Определены следующие значения:
- Processing - Очередь журналов событий находится в состоянии
поиска результатов:
- Halted - Новые сообщения о событиях не будут более добавлять
ся в очередь:
- Current - Очередь журналов событий содержит все имеющиеся
на текущий момент сообщения о событиях;
- Error - Метаданные очереди сообщений о событиях некоррект
ные. либо возникли другие ошибки, которые не позволяют включать со
общения о событиях в очередь. Строка "Error" может завершаться
про извольным текстом, зависящим от реализации.
Обязательно
20.6 Замечания о безопасности при ведении журналов событий
Точность и целостность временных меток элементов журнала зависят от точности и целостности
часов, использующихся для их установки. Точные временные метки важны для разрешения проблем,
экспертного анализа распределенных атак, разрешения споров идоказательства транзакций, чувстви
тельных к времени. В частности, устранение ошибок, безопасность, учет и аутентификация основыва
ются на корреляции событий (т.е., точном знании порядка событий), и эти соображения безопасности
зависят от хорошей синхронизации времени.
Спецификация точности и целостности временных меток находится за рамками настоящего стандар
та; тем не менее, для демонстрации надежности временных меток их следует приводить к стандартному
времени, и необходимо показать, что системное время но может быть произвольным образом изменено.
21 Очереди уведомлений
Облачная система хранения может опционально реализовывать функциональность уведомле
ний. Наличие этой функциональности обозначается присутствием соответствующих общесистемных
опций и предполагает поддержку очередей CDMI™.
Очереди уведомлений позволяют CDMI клиентам эффективно обнаруживать, какие изменения
происходят в системе. Так как очередь уведомлений является хранимой (persistent), не требуется, что бы
клиент постоянно поддерживал сессию. Если разными клиентами используются различные очереди
уведомлений, каждый клиент действует независимо от остальных (например, приложение для управ
ления хранением может использовать очередь уведомлений для поддержания своей базы данных без
необходимости проводить полное сканирование контейнера для определения, какие объекты данных
были добавлены, изменены или удалены).
Если клиент запрашивает получение уведомлений, в первую очередь он может проверить, спо
собна ли система генерировать такие уведомления (проверка наличия опции cdmi_notificat»on среди
опций корневого контейнера). Если эта опция отсутствует, создание очереди уведомлений будет успеш
ным. но никакие уведомления не будут добавляться в эту очередь.
Для создания очереди уведомлений клиент создает обычную очередь CDMI и добавляет метадан
ные. указывающие системе хранения, что данная очередь должна обрабатываться как очередь уведом
лений. Эти метаданные также показывают системе, какие типы уведомлений должны генерироваться,
и какая информация должна включаться в каждое уведомление.
После создания очереди уведомлений последующие подходящие события должны приводить к
возникновению соответствующих уведомлений и добавлению их в очередь. Стандарт CDMI не требует
специального упорядочения уведомлений, и клиентдолжен быть способен обрабатывать уведомления,
поступившие вне очереди.
При создании очереди уведомлений необходимо предоставить метаданные, указанные в таблице
122. Попытки изменения метаданных, указанных в этой таблице, должны приводить к ошибке HTTP 403
Forbidden. После создания очереди уведомлений, элементы этих метаданных не должны меняться,
за исключением cdmi_queue_type; последний элемент может быть только удален, показывая системе,
что очередь уведомлений теперь не должна принимать уведомления и должна обрабатываться как
обыч ная очередь CDMI.
146