ГОСТ Р ИСО/МЭК 17826-2015
- предоставление механизмадля записи действий, выполненныхCDMI клиентом на CDMI сервере:
- предоставление механизмов защиты данных в фоновом режиме:
- предоставление механизмов контролируемого удаления данных:
- предоставление механизма для определения набора опций безопасности конкретной реализации.
Меры безопасности, включенные в CDMI. можно описать как:
- безопасная передача;
- аутентификация пользователей и сущностей:
- авторизация и контрольдоступа;
- целостность данных;
- очистка данных и среды;
- удерживание данных;
- защита от вредоносных действий;
- шифрование данных в фоновом режиме;
- опции безопасности.
За исключением безопасности передачи и опций безопасности, которые обязательны для реали
зации. остальные меры безопасности существенно зависят от конкретной реализации.
Если безопасность является важной задачей. CDMI клиент должен начинать работу с серии по
исков опций безопасности (см. подпункт 12.1.1) для определения точной природы возможных мер без
опасности. Основываясь на значениях опций и оценке рисков, принимается решение о том. может ли
использоваться данный сервер CDMI. Это особенно важно, если в облаке будет храниться ценные дан
ные или данные ограниченного доступа, и требуется определенная зашита (шифрование) или особая
обработка данных (например, опция записи и просмотра всех выполняемых действий).
HTTP является обязательным механизмом передачи данных, a HTTP над TLS (то есть. HTTPS)
является механизмом, используемым для безопасного взаимодействия между клиентами и сервером
CDMI. Для обеспечения безопасности и совместимости, все реализации CDMI должны поддерживать
протокол безопасности транспортного уровня (Transport Layer Security. TLS) как описано в приложении А.
но его использование клиентами и сервером CDMI опционально.
5.13 Необходимая поддержка HTTP
5.13.1 Требования поддержки RFC 2616
Совместимая реализация CDMI должна также включать реализацию RFC2616 (см. [RFC 2616])
(т.е., HTTP 1.1). Перечисленные ниже примеры описывают некоторые части RFC 2616. которые должны
поддерживаться, но этот список не является исчерпывающим.
5.13.2 Согласование типа содержимого
Для операций CDMI используются типы медиа CDMI объектов, определенные в [RFC 6208].
Клиент можетопционально предоставлять заголовок HTTPAccept согласно 14.1 RFC 2616. Если кли
ент требует, чтобы в ответе содержался определенный тип медиа CDMI. соответствующий типдолжен быть
указан в заголовке Accept. Иначе, заголовок можетсодержать «Т» или список типов, или быть опущен.
Если в сообщении-запросе присутствует тело, клиент должен включать заголовок Content-Type
согласно пункту 14.17 RFC 2616. Если в таком случае клиент не предоставляет заголовок Content-Type
содержимого или тип медиа в заголовке Content-Type не соответствует существующему типу ресурса,
сервер должен вернуть код состояния HTTP 400 Bad Request.
Если в сообщении-ответе присутствует тело, сервердолжен предоставить заголовок Content-Type.
Настоящий стандарт допускает дальнейшие согласования типа содержимого (например, в 9.3 от
сутствие заголовка Content-Type несет особую информацию).
5.13.3 Поддержка диапазона
Сервер должен поддерживать заголовки HTTP Range и ответы с частичным содержимым (см.
14.16 RFC 2616).
5.13.4 Экранирование в URI
Ковсем строкам, использованным в URI.должно применяться экранирование зарезервированных сим
волов знаком процента (%), определенное в RFC 3986. Это касается имен полей, предоставленных пользо
вателем. имен метаданных, имен объектов, имен контейнеров и имендоменов, использованных в URI.
12