Хорошие продукты и сервисы
Наш Поиск (введите запрос без опечаток)
Наш Поиск по гостам (введите запрос без опечаток)
Поиск
Поиск
Бизнес гороскоп на текущую неделю c 22.12.2025 по 28.12.2025
Открыть шифр замка из трёх цифр с ограничениями

ГОСТ Р ИСО/МЭК 40210-2014; Страница 30

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы ГОСТ Р ЕН 257-2004 Термостаты (терморегуляторы) механические для газовых аппаратов. Общие технические требования и методы испытаний Mechanical thermostats (thermoregulators) for gas appliances. General technical requirements and test methods (Настоящий стандарт устанавливает конструктивные и функциональные требования к механическим терморегуляторам для газовых аппаратов, определяет терминологию, маркировку и методы проведения испытаний. Стандарт распространяется на механические терморегуляторы, которые прямо или косвенно осуществляют регулирование температуры с помощью встроенного газового клапана и не нуждается в подводе электрической энергии от внешнего источника. Требования настоящего стандарта применимы к терморегуляторам всех газовых аппаратов, используемых для нагрева или охлаждения, работающих на природном и (или) сжиженном газах. Настоящий стандарт распространяется на терморегуляторы, которые встраивают в газовые аппараты, устанавливаемые в закрытом помещении) ГОСТ Р ИСО/МЭК 20000-3-2014 Информационная технология. Управление услугами. Часть 3. Руководство по определению области применения и применимости ИСО/МЭК 20000-1 (В данную часть стандарта ИСО/МЭК 20000 входит руководство по определению области применения и применимости документа ИСО/МЭК 20000-1, а также по демонстрации соответствия описанным в нем требованиям. Принципы, установленные в этой части стандарта ИСО/МЭК 20000, помогут поставщику услуг в планировании улучшения качества услуг и (или) в подготовке к оценке на соответствие требованиям документа ИСО/МЭК 20000-1. Настоящая часть стандарта ИСО/МЭК 20000 поможет определить, применим ли документ ИСО/МЭК 20000-1 к конкретным случаям, встречающимся у поставщиков услуг. В ней на примерах поясняется, как можно определить область применения SMS вне зависимости от того, имеет ли поставщик услуг опыт в определении областей применения других систем управления. В состав документа включено руководство по типам оценки соответствия и стандартам оценки) ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества (Настоящий стандарт содержит следующую информацию:. - требования к определению ЭПК как часть спецификации требований качества продукции с примерами [пункт 6.2 (таблицы 1 и 2)];. - начальное множество элементов ЭПК, приведенное в виде примеров [таблица A.1 (приложение A)];. - руководство для определения и количественной характеристики свойств продукции (согласно целевому назначению) для ЭПК (приложение B). Руководство предназначено для разработчиков, приобретателей и независимых оценщиков продукции, особенно тех, кто ответственен за определение требований и оценку качества продукции, но не ограничивается ими. Настоящий стандарт применим, если элементы показателей качества, которые предполагается использовать для формирования показателей качества, определены в соответствии с ИСО/МЭК 25022, ИСО/МЭК 25023 и ИСО/МЭК 25024)
Страница 30
Страница 1 Untitled document
ГОСТ Р ИСО/МЭК 402102014
Нижележащий протокол МОЖЕТ определить базовый URI, который может использоваться в качестве
базового URI для конверта SOAP (см. раздел 7 и SOAP 1.2 часть 2 [Часть 2 SOAP], раздел Привязка HTTP).
SOAP не определяет никаких правил эквивалентности для URI в целом, так как это определено от
дельными схемами URI и RFC 3986 [RFC 3986]. Однако из-за несогласованности относительно правил
эквивалентности URI во многих существующих синтаксических анализаторах URI. РЕКОМЕНДУЕТСЯ,
чтобы для определения эквивалентности значений URI. используемых в сообщении SOAP, отправите
ли SOAP не полагались на какиеибо специальные правила эквивалентности у получателей SOAP.
Использования IP-адресов в URIs СЛЕДУЕТ избегать всегда, когда это возможно (см. RFC 1900
[RFC 1900]). Однако текстовый формат адресов IPv6 в URI СЛЕДУЕТ поддерживать, как это описано
RFC 3986 [RFC 3986].
SOAP не устанавливает априорных ограничений на длину URI. Любой узел SOAP ДОЛЖЕН быть в
состоянии обработать передаваемый URI любой длины. Как отправители SOAP, так и получатели SOAP
ДОЛЖНЫ оперировать с URI длиной по крайней мере 2048 символов.
10 Соображения безопасности
Структура обмена сообщениями SOAP непосредственно не обеспечивает механизмы, позволяющие
контролировать управление доступом, конфиденциальность, целостность и неотказуемость. Подобные
механизмы могут быть добавлены как расширения SOAP посредством применения модели расширяемо
сти SOAP (см. раздел 6). В данном разделе описываются соображения безопасности, которые должны
быть учтены разработчиками и конструкторами при разработке и эксплуатации подобных механизмов.
Разработчики SOAP должны учитывать возможность появления вредоносных приложений SOAP,
намеренно отправляющих вредоносные данные на узел SOAP (см. раздел 5). Настоятельно рекомен
дуется. чтобы узел SOAP, получающий сообщение SOAP, был способен оценить, насколько он может
доверять отправителю сообщения SOAP и содержимому этого сообщения.
10.1 Узлы SOAP
SOAP позволяет пересылать данные приложений как в блоках заголовка SOAP, так и в содержи
мом тела SOAP. Обработка блока заголовка SOAP может включать в себя побочные эффекты, такие
как изменения состояния, ведение журнала или формирование дополнительных сообщений. Для любо
го сценария развертывания настоятельно рекомендуется, чтобы узлом SOAP обрабатывались только
строго специфицированные блоки заголовка SOAP с хорошо понятыми последствиями любых побоч
ных эффектов для безопасности.
Точно так же обработка тела SOAP может вызвать возникновение побочных эффектов, которые
могут приводить к серьезным последствиям для принимающего узла SOAP в случае, если тело понято не
должным образом. Настоятельно рекомендуется, чтобы обрабатывалось только строго определен ное
содержимое тела с известными последствиями для безопасности.
Соображения безопасности, однако, не должны ограничиваться распознаванием только непо
средственных дочерних элементов блока заголовка SOAP и тела SOAP. Разработчики должны обратить
особое внимание на последствия для безопасности всех данных, передаваемых в сообщении SOAP,
которое может вызвать удаленное выполнение каких-либо действий в среде получателя. К этому от
носятся не только данные, выраженные как свойства инфо-набора XML, но и данные, которые могут
быть закодированы как значения свойств, включая двоичные данные или параметры, например строки
запроса URI. Прежде чем принять данные любого типа, приложение должно знать о конкретных по
следствиях для безопасности, связанных с этими данными в контексте их использования.
Если обработка различных частей сообщения SOAP обеспечивается посредством программного
обеспечения с модульной архитектурой, то разработчики SOAP должны принять все возможные меры
для того, чтобы обеспечить каждый модуль полной информацией о контексте безопасности. Например,
без знания контекста, в котором оно получено, тело SOAP не должно обрабатываться.
10.2 Посредники SOAP
По своей сущности. SOAP обеспечивает модель распределенной разработки, которая может вклю
чать прохождение сообщения SOAP через несколько узлов SOAP (см. раздел 5). Посредники SOAP это
по определению узлы в середине, представляющие возможность для атак типа «человек посередине»
(man-in-the-middle). Нарушения правил безопасности всистемах, которыедействуют как посредники SOAP,
26