ГОСТ ISO/IEC TS 19249-2021

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Информационные технологии

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

Каталог принципов построения архитектуры и проектирования безопасных продуктов, систем и приложений

Information technology. Security techniques. Catalogue of architectural and design principles for secure products, systems and applications

МКС 35.030

Дата введения 2021-11-30

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"

Сведения о стандарте

1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Федеральный исследовательский центр "Информатика и управление" Российской академии наук" (ФИЦ ИУ РАН), Обществом с ограниченной ответственностью "Центр безопасности информации" и Обществом с ограниченной ответственностью "Информационно-аналитический центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 5

2 ВНЕСЕН Межгосударственным техническим комитетом по стандартизации МТК 022 "Информационные технологии"

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 30 июня 2021 г. N 141-П)

За принятие проголосовали:

(Поправка. ИУС N 11-2021).

4 Приказом Федерального агентства по техническому регулированию и метрологии от 2 июля 2021 г. N 611-ст межгосударственный стандарт ГОСТ ISO/IEC TS 19249-2021 введен в действие в качестве национального стандарта Российской Федерации с 30 ноября 2021 г.

5 Настоящий стандарт идентичен международному документу ISO/IEC TS 19249:2017* "Информационные технологии. Методы и средства обеспечения безопасности. Каталог принципов построения архитектуры и проектирования безопасных продуктов, систем и приложений" ("Information technology - Security techniques - Catalogue of architectural and design principles for secure products, systems and applications", IDT).

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.

ISO/IEC TS 19249:2017 разработан подкомитетом SC 27 "Информационная безопасность, кибербезопасность и защита конфиденциальности" Совместного технического комитета JTC 1 "Информационные технологии" Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC).

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

Дополнительные сноски в тексте стандарта, выделенные курсивом*, приведены для пояснения текста оригинала

________________

* В оригинале обозначения и номера стандартов и нормативных документов приводятся обычным шрифтом. - Примечание изготовителя базы данных.

6 ВВЕДЕН ВПЕРВЫЕ

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

В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге "Межгосударственные стандарты".

ВНЕСЕНА поправка, опубликованная в ИУС N 11, 2021 год, введенная в действие с 03.09.2021

Поправка внесена изготовителем базы данных

Введение

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

Цель настоящего стандарта - описать эти принципы структурированным образом, охарактеризовать сам принцип, описать, как его можно использовать, как он может поддерживать безопасность и как это может помочь в оценке безопасности продукта, системы или приложения. Настоящий стандарт может применяться при проведении оценки информационной безопасности, выполняемой с использованием ISO/IEC 15408 и ISO/IEC 18045.

     1 Область применения

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

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

Настоящий стандарт относится к области применения ISO/IEC 15408 и ISO/IEC 18045 и адресован как разработчикам, так и специалистам по оценке безопасности продуктов, систем и приложений.

Настоящий стандарт не устанавливает никаких требований к оценке, процессу оценки или реализации.

     2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения)]:

ISO/IEC 15408-1, Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model (Информационные технологии. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель)

ISO/IEC 15408-2, Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional components (Информационные технологии. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности)

ISO/IEC 15408-3, Information technology - Security techniques - Evaluation criteria for IT security - Part 3: Security assurance components (Информационные технологии. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности)

ISO/IEC 18045, Information technology - Security techniques - Methodology for IT security evaluation (Информационные технологии. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий)

     3 Термины и определения

В настоящем стандарте применены термины по ISO/IEC 15408 и ISO/IEC 18045, а также следующие термины с соответствующими определениями:

3.1 свойство безопасности (security property): Свойство системы или приложения, которое имеет решающее значение для достижения целей безопасности, определенных для системы или приложения.

3.2 атрибут безопасности (security relevant attribute): Атрибут, назначенный объекту, субъекту или пользователю системы или приложения, который используется для обеспечения соблюдения политики безопасности.

3.3 привилегия (privilege): Конкретный атрибут безопасности для субъекта или пользователя, который позволяет этому пользователю или субъекту выполнять специальные действия, связанные с этим атрибутом безопасности.

3.4 служба прозрачного шифрования (transparent encryption service): Услуга, предоставляемая системой, которая либо всегда включена, либо может быть включена администратором, автоматически зашифровывающая и дешифровывающая данные в постоянном хранилище или в каналах связи, о которой пользователь, хранящий или передающий данные, не знает, что данная служба шифрования работает.

Примечание - Примерами являются службы автоматического шифрования дисков (например, самошифрующиеся диски) или туннелирование канала связи через линию связи, защищенный IPSec или TLS.

     4 Принципы построения архитектуры безопасных продуктов, систем и приложений

     4.1 Общие положения

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

Существует несколько фундаментальных принципов безопасности, которые необходимо соблюдать независимо от принципов построения архитектуры или проектирования. Они известны уже давно и впервые были задокументированы в исследовании, проведенном по поручению Правительства США в 1972 году [1]. Фундаментальные принципы:

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

- функции безопасности должны быть вызваны каждый раз, когда необходимо осуществить выполнение политики безопасности;

- часть продукта, системы или приложения, реализующая функции безопасности, должна быть достаточно мала, чтобы ее можно было проанализировать на корректность и возможные побочные эффекты, критичные для безопасности.

В более поздних отчетах [2] части продукта, которые должны быть доверенными для выполнения политик безопасности и которые удовлетворяют вышеописанным принципам безопасности, называют "доверенной вычислительной базой" или ДВБ.

Ряд принципов проектирования, упомянутых в этой спецификации, уже был введен в [3] в 1974 г.

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

     4.2 Разделение на домены

4.2.1 Общие положения

Разделение на домены - это принцип инкапсуляции компонентов, данных и/или программ в отдельные объекты, которыми можно управлять независимо, включая назначение прав и других атрибутов безопасности каждому домену. Между доменами могут быть определены каналы связи, реализованные таким образом, чтобы контролировать взаимодействие между доменами, а также позволять домену, получающему запрос из другого домена по каналу связи, идентифицировать запрашивающий домен и соответствующе реагировать на полученный запрос.

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

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

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

4.2.2 Принципы определения структур доменов

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

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