ГОСТ Р ИСО/МЭК 27034-3-2021. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 3. Процесс менеджмента безопасности приложений
6.2 Оценка рисков безопасности приложений
6.2.1 Общие положения
Второй этап ПМБП соответствует процессу оценки риска для конкретного проекта приложения.
Данный этап соответствует этапу "Оценка риска информационной безопасности" и части этапа "Обработка рисков информационной безопасности" процесса менеджмента рисков, приведенном в ИСО/МЭК 27005, но с более высоким уровнем детализации и областью действий, ограниченной одним проектом приложения.
Согласно ИСО/МЭК 27005 "в процессе оценки риска устанавливается ценность информационных активов, выявляются потенциальные угрозы и уязвимости, которые существуют или могут существовать, определяются существующие меры безопасности и их воздействие на идентифицированные риски, определяются возможные последствия и, наконец, назначаются приоритеты установленным рискам, а также осуществляется их ранжирование по критериям оценки риска, зафиксированным при установлении контекста".
Процесс оценки рисков включает в себя этапы определения, анализа и оценки рисков. К данному этапу ПМБП также относится "выбор вариантов обработки рисков" для определения приемлемого и утвержденного уровня риска. Поэтому данный этап соответствует этапу "выбор вариантов обработки рисков" в процессе менеджмента рисков, приведенном в ИСО/МЭК 27005.
Данный этап ПМБП также устанавливает требования безопасности приложения, которые будут использованы для выбора необходимых МОБП для приложения, как показано на рисунке 3.
Рисунок 3 - Логический поток от рисков безопасности
приложения к снижению рисков
Риски безопасности приложения, вытекающие из его контекста и среды [которые определены на шаге 1 (подраздел 6.1)], устанавливают требования безопасности и соответствующий набор применимых МОБП. На рисунке 3 обозначение "n..n" соответствует отношению "многие ко многим", а "1..n" - "один ко многим".
Этап оценки риска ПМБП завершается определением целевого уровня доверия приложения [см. ИСО/МЭК 27034-1:2011 (пункт 8.2.4)], который должен быть одобрен его владельцем.
Примечания
1 Методология анализа рисков безопасности на уровне организации, возможно, не позволяет идентифицировать все риски и обеспечения безопасности, необходимые для безопасной эксплуатации приложения. Чтобы используемый метод анализа рисков безопасности был эффективен, он должен быть специально разработан или адаптирован; в этом случае данный метод анализа позволит гарантировать, что специфические особенности приложения и его среды принимаются во внимание.
2 Для приложений, которые работают с персональными данными, риски для конфиденциальности также учитываются в процессе оценки риска.
3 Риски для конфиденциальности зависят от применимых законов о неприкосновенности частной жизни и местных нормативных актов, которые упоминаются в регулятивном контексте.
6.2.2 Назначение
Задачей процесса оценки рисков является:
a) для проекта: определить, проанализировать и оценить риски для безопасности, сформулировать итоговые требования безопасности, целевой уровень доверия приложения и необходимые МОБП для защиты приложения;
b) для организации: консолидировать и поддерживать информацию о рисках, связанных с приложением, в НСО.
6.2.3 Результаты
Результатами выполнения мероприятий данного процесса являются:
a) создание предварительной версии НСП, которая содержит информацию о среде приложения, а также информацию, полученную в результате выполнения этого процесса, в том числе:
1) список угроз для безопасности приложения;
2) требования безопасности для снижения рисков;
3) целевой уровень доверия приложения, определяющий список МОБП, которые потребуются в течение жизненного цикла приложения;
b) обновление информации о безопасности приложения в НСО.
6.2.4 Мероприятия по реализации
В таблице 5 показаны роли и обязанности по выполнению действий в ходе реализации процесса "Оценка рисков безопасности приложения".
Таблица 5
Диаграмма RACI для реализации этапа ПМБП
"Оценка рисков безопасности приложения"
Мероприятия по реализации | Группа НСО | Владелец приложения | Проектная группа |
1) Выявление и оценка рисков безопасности, связанных с приложением | C | A/R | C |
2) Выявление и оценка степени, в которой ранее выявленные угрозы безопасности были устранены в приложении | C | A | R |
3) Определение минимальных требований безопасности для приложения (с учетом недопустимых угроз безопасности) | C | A/R | C |
4) Определение целевого уровня доверия приложений для приложения, отвечающего всем определенным требованиям безопасности | C | A/R | C |
5) Подтверждение и утверждение целевого уровня доверия приложения | I | A | R |
6) Сбор информации по результатам анализа рисков в соответствии с 6.1.3 | C | A/R | C |
7) Обновление содержимого НСП | A | I | R |
8) Обновление содержимого НСО | A/R | C | C |
9) Обеспечение доступности к информации заинтересованных сторон | I | A/R | I |
6.2.5 Мероприятия по верификации
В таблице 6 приведены роли и обязанности, связанные с действиями по верификации процесса "Определение среды и требований приложения".
Таблица 6
Диаграмма RACI для верификации этапа ПМБП
"Оценка рисков безопасности приложения"
Мероприятия по верификации | Менеджеры | Владелец приложения | Группа проверки |
1) Сбор исходных данных и результатов анализа рисков безопасности приложений | C | C/I | A/R |
2) Сбор исходных данных и результатов анализа рисков безопасности приложения | C | C/I | A/R |
3) Гарантия того, что риск безопасности приложения был точно оценен с учетом определенного набора мер обеспечения безопасности приложения | C | C/I | A/R |
4) Подтверждение того, что целевой уровень доверия приложения был определен и утвержден | C | C/I | A/R |
5) Подтверждение того, что владелец приложения согласился с остаточными рисками, связанными с приложением | C | C/I | A/R |
6.2.6 Рекомендации
6.2.6.1 Область оценки рисков для безопасности приложения
Во время оценки рисков следует учитывать риски, связанные с процессами, действиями и действующими субъектами, участвующими в четырех уровнях жизненного цикла безопасности приложений (см. рисунок 4). Важно отметить, что жизненный цикл включает в себя не только этапы подготовки. Риски, относящиеся к этапам эксплуатации, не менее важны.
Рисунок 4 - Пример жизненного цикла безопасности приложения
Поэтому ПМБП распространяется на все этапы и уровни жизненного цикла. Это особенно актуально для организаций, эксплуатирующих приложения, в отличие от организаций, которые выступают только как поставщики.
6.2.6.2 Идентификация рисков, связанных с приложением
Идентификация рисков для безопасности приложения - это процесс поиска, распознавания и описания рисков, касающихся информации, получаемой, хранимой, обрабатываемой, используемой и передаваемой приложением. Следует учитывать риски, независимо от того, находится ли их источник под контролем организации, включая бизнес-контекст, регулятивный и технологический контексты.
Идентификация рисков включает в себя идентификацию источников риска, событий, их причин и потенциальных последствий. Здесь следует учитывать исторические данные, теоретический анализ, обоснованные и экспертные мнения, потребности заинтересованных сторон.
6.2.6.3 Анализ рисков, связанных с приложением
6.2.6.3.1 Общие положения
Анализ рисков является первым шагом в процессе оценки риска. Анализ рисков для приложений часто выполняется в два этапа:
a) высокоуровневый анализ рисков;
b) детальный анализ рисков.
6.2.6.3.2 Высокоуровневый анализ рисков безопасности приложения
Процесс высокоуровневого анализа рисков безопасности приложения обычно выполняется на этапе подготовки в жизненном цикле приложения, как приведено в ИСО/МЭК 27034-1:2011 (подпункт 8.2.2.1).
Высокоуровневый анализ рисков представляет собой простой эмпирический метод для определения целевого уровня доверия приложения согласно базовым спецификациям, а также регулятивному и технологическому контекстам совместно с бизнес-контекстом.
Владелец конкретного проекта приложения должен четко определить роль с обязанностью проводить этот анализ с помощью адекватной методологии на уровне приложения. Методология анализа рисков на уровне организации может не подойти для этой задачи.
Ниже приведены примеры вопросов, задаваемых в ходе выполнения высокоуровневого анализа рисков приложения и направленных на определение спецификаций и контекстов приложений.
Примеры
1 Применяется ли приложение только внутренними пользователями или используется через Интернет?
2 Это веб-приложение или приложение для ПК?
3 Обрабатывает ли приложение данные кредитных карт?
4 Имеется ли в приложении компонент для мобильных устройств?
6.2.6.3.3 Детальный анализ рисков безопасности приложения
Процесс детального анализа рисков выполняется на этапе реализации жизненного цикла приложения, как приведено в ИСО/МЭК 27034-1:2011 (подпункт 8.2.2.2).
Этот процесс более точно определяет связанные с приложением остаточные риски перед рассмотрением любых элементов управления безопасностью приложения и подтверждает целевой уровень доверия приложения, определенный в ходе высокоуровневого анализа рисков с учетом подробных спецификаций приложения и технологических особенностей организации, а также регулятивного контекста и бизнес-контекста.
В результате детального анализа рисков владелец приложения может изменить целевой уровень доверия приложения для проекта приложения, тем самым изменив МОБП для проекта. В результате изменятся вовлеченные действующие субъекты и оценочная стоимость проекта. Однако последствия обновления МОБП для безопасности легко прогнозируются, поскольку такая информация, как действующие субъекты, профессиональная квалификация и оценочная стоимость, уже являются частью каждой МОБП, они задокументированы в библиотеке МОБП организации.
Владелец конкретного проекта приложения должен четко определить роль с обязанностью проводить этот анализ с помощью адекватной методологии на уровне приложения. Методология анализа рисков на уровне организации может не подойти для этой задачи.
Ниже приведены примеры вопросов, задаваемых в ходе выполнения детального анализа рисков для приложения.
Пример 1 - Предоставляет ли приложение функцию аутентификации, включающую в себя защиту учетных данных?
Пример 2 - Используется ли для аутентификации база данных или Active Directory?
Пример 3 - Поддерживает ли приложение авторизацию на основе ролей?
Пример 4 - Включает ли приложение код JavaScript?
На основе ответов на вопросы, которые задаются в процессе анализа рисков, формулируются требования безопасности. Эти требования безопасности должны быть задокументированы в НСП (подробнее см. подраздел 6.3). Например:
Пример 5 - Если приложение предоставляет функцию аутентификации на основе форм (учитывается ответ на вопрос в ходе анализа рисков), то функция аутентификации должна быть защищена от атак перебора пользователей (это часть требований безопасности приложения).
6.2.6.3.4 Методы детального анализа рисков приложений
Организация может включить в свою НСО определенные общеизвестные методики, примеры которых приведены ниже.
6.2.6.3.4.1 Моделирование угроз
Моделирование угроз используется в средах, где существует значительный риск безопасности. Такая практика позволяет проектным группам структурированным образом анализировать, документировать и обсуждать последствия применения угроз с целью обеспечения безопасности проектов в контексте их планируемой среды эксплуатации. Моделирование угроз также позволяет учитывать риски безопасности на уровне компонентов или приложения.
Моделирование угроз выполняется группой, включающей в себя руководителей программ/проектов, разработчиков и тестировщиков, и является основной задачей анализа безопасности, выполняемой на этапе разработки программного обеспечения.
6.2.6.3.4.2 Анализ модели угроз и поверхности атаки
Обычно приложение отклоняется от функциональных и проектных спецификаций, определенных на этапах формулирования требований и проектирования. В результате проектные группы должны пересмотреть модели угроз и результаты анализа поверхности атаки определенного приложения, когда код будет готов. Такой пересмотр гарантирует, что любые изменения в проекте или реализации были учтены, и что любые новые векторы атак, появившиеся в результате изменений, были рассмотрены и минимизированы. Модель угроз и процесс пересмотра поверхности атаки могут привести к изменению целевого уровня доверия приложения.
Для проектных команд, которые используют каскадную модель разработки, такой пересмотр выполняется после этапа реализации или после внесения серьезных изменений. В модели гибкой разработки (Agile) это действие должно выполняться на каждой итерации модели.
6.2.6.4 Анализ рисков, связанных с приложением
Согласно ИСО/МЭК 27005 "оценивание рисков основывается на понимании рисков, полученном при анализе рисков, и используется при принятии решений о будущих действиях". Решения должны включать в себя следующее:
a) необходимость в какой-либо процедуре;
b) приоритеты при обработке рисков с учетом установленных значений уровней рисков.
В настоящем стандарте данный этап заключается в выборе целевого уровня доверия приложения, который, в свою очередь, определяет, какие меры обеспечения безопасности приложений необходимо применить для обработки рисков.
В результате оценки рисков владелец приложения может изменить целевой уровень доверия приложения, определенный для проекта приложения. Применяемые МОБП, выбранные для проекта, будут изменены, что повлияет на вовлеченных действующих субъектов и оценочную стоимость проекта.
6.2.6.5 Мероприятия по оценке рисков, связанных с безопасностью приложений
Основные действия, которые организации могут выполнять в ходе оценки рисков безопасности приложений, включают в себя:
a) получение необходимой информации от НСП. Эта информация, обычно предоставляемая на первом этапе ПМБП, должна включать в себя:
1) требования приложения;
2) среду приложения:
i) бизнес-контекст;
ii) регулятивный контекст;
iii) технологический контекст;
3) информацию, полученную, сохраненную, обработанную или предоставленную приложением;
4) категорию безопасности для этой информации;
5) поток этой информации в приложении;
6) определение критической для организации информации;
7) спецификации, функции и компоненты приложения, а также информацию, с которой они работают;
8) процессы приложения, процессы организации, взаимодействующие с приложением, и информацию, с которой они работают;
9) действующие субъекты, вовлеченные в эти спецификации и процессы;
b) категоризация спецификаций, процессов и действующих субъектов в соответствии с категоризацией информации, с которой они работают (они наследуют категории информации);
c) определение критических спецификаций, процессов и действующих субъектов;
d) определение угроз для критической информации на основе среды приложения и критических спецификаций, процессов и действующих субъектов (подпункт 6.2.6.3.4);
e) определение уязвимостей на основе среды приложения и критических спецификаций, процессов и действующих субъектов;
f) определение влияния на организацию на основе внутренней и эксплуатационной ценности критической информации в приложении;
g) определение рисков безопасности приложения на основе собранной выше информации; определение приемлемых и неприемлемых рисков на основе критериев организации;
h) определение стратегии по снижению этих рисков;
i) для каждого неприемлемого риска необходимо определить предпочтительную стратегию снижения, например: обработку, перенос, допущение или прекращение;
j) для каждого неприемлемого риска необходимо определить требования безопасности приложения.
6.2.6.6 Требования безопасности приложений
В большинстве проектов приложений риски безопасности должны учитываться после того, как требования к проекту выполнены, чтобы убедиться, что итоговые требования безопасности также учитывают риски безопасности, возникающие из требований к проекту (например, функциональные требования). После определения эти требования безопасности могут создать процесс обратной связи и повлиять на требования к проекту приложения. Снижение рисков безопасности оказывается дешевле, если это сделано на этапе проектирования и до реализации кода.
Цель определения требований безопасности состоит в том, чтобы четко понять, каких результатов следует ожидать от МОБП, которые будут реализованы для снижения риска до приемлемого уровня.
Основное различие между требованиями к программному обеспечению (или системными требованиями) и требованиями безопасности заключается в том, что требования к программному обеспечению и системам устанавливаются для удовлетворения потребностей (т.е. потребности организаций, пользователей или приложения), а требования безопасности устанавливаются для минимизации рисков.
Требования безопасности должны также определить, как безопасно внедрить и развернуть все функциональные возможности, предоставляемые конкретной функцией. Проектная группа должна проверить проектные спецификации на соответствие функциональной спецификации приложения. Эта группа должна обеспечивать сквозное покрытие, включающее в себя устройства, которые обращаются к системе приложения, межсистемным интерфейсам и любым внешним соединениям.
Определение точных и надежных требований безопасности, охватывающих все риски, которым подвержено приложение, бывает затруднено. В рекомендациях, приведенных далее, предлагается специальная таксономия, которую некоторые организации могут найти полезной.
Тип требований безопасности приложений определяется путем идентификации действующего субъекта, к которому относится это требование. Например, если требование безопасности указывает, что пользователь должен ввести пароль, это требование будет определено как требование к пользователю. Если требование безопасности предписывает, что приложение должно вести журнал определенных критических транзакций, это требование будет определено как системное требование.
| - тип требования; |
| - контейнер (документы, схемы базы данных и т.д.) |
Рисунок 5 - Типы требований безопасности приложения
Как показано на рисунке 5, требования безопасности, как и требования к программному обеспечению, могут быть разделены на две категории (функциональные и нефункциональные), четыре уровня (бизнес, пользователи, функции и инфраструктура), а также 12 типов:
a) Бизнес-требования. Требование обеспечения безопасности бизнеса направлено на устранение как минимум одного риска для обеспечения безопасности из бизнес-контекста организации, такого как: практики, цели организации, информация для защиты целевой клиентуры и т.д.
b) Бизнес-правила. Правило обеспечения безопасности бизнеса устраняет по крайней мере одну угрозу безопасности из правил работы организации, таких как директивы, внутренние правила, кодексы поведения и т.д.
c) Регулятивные требования. Регулятивное требование направлено как минимум на один риск для обеспечения безопасности из регулятивного контекста, которому подвержена организация.
d) Пользовательские требования. Пользовательское требование устраняет по крайней мере одну угрозу безопасности от действий, которые могут быть выполнены субъектом (менеджером, членом технической группы, оператором, пользователем, слушателем) во время работы с приложением.
e) Требования к квалификации. Требования к квалификации к безопасности направлено на устранение как минимум одного риска безопасности из ограничений или квалификаций до того, как действующему субъекту будет разрешено выполнить действие в среде разработки или среде эксплуатации приложений. Этот тип требований может применяться к субъекту или системному компоненту.
Примеры
1 Прежде чем получить разрешение на разработку нового компонента Java, разработчик должен доказать необходимую квалификацию и знания, например предоставить диплом/сертификат, подтвердить минимальное количество лет опыта.
2 Прежде чем компонент приложения будет развернут в среде, он должен быть сертифицирован как способный обнаруживать и реагировать на распределенные атаки типа "отказ в обслуживании", попытки несанкционированного изменения данных или сбои другого компонента системы.
f) Атрибуты качества. Атрибут качества учитывает, по крайней мере, один риск безопасности, связанный с недостижением целей в области качества приложения (возможность повторного использования, удобство использования, целостность, переносимость, совместимость, возможность обслуживания и т.д.).
g) Системные требования. Системное требование безопасности направлено как минимум на одну угрозу безопасности со стороны услуг и функций, предлагаемых приложением.
h) Требования к процессу. Требование к безопасности процесса направлено на устранение как минимум одного риска безопасности, вызванного или затронутого какими-либо процессами внедрения или эксплуатации (процессы разработки, развертывания, делегирования, использования, обслуживания и архивирования, а также непредвиденные обстоятельства.
i) Функциональные требования. Требование к функциональной безопасности учитывает как минимум один риск безопасности, связанный с функциями, предлагаемыми системой (онлайн-платежи, передача данных, корзина покупок, удаленное управление и т.д.).
j) Внешние интерфейсы. Требование к безопасности внешнего интерфейса устраняет по крайней мере одну угрозу безопасности, исходящую от различных интерфейсов, предлагаемых системой (веб-интерфейсы и интерфейсы связи с другими приложениями).
k) Требования к инфраструктуре. Требование к безопасности инфраструктуры направлено как минимум на один риск безопасности, исходящий от среды физической инфраструктуры, которая поддерживает приложение.
l) Ограничения. Ограничение безопасности устраняет по крайней мере одну угрозу безопасности, исходящую от ограничений, наложенных на приложение или требуемых для него. Например, приложение должно быть доступно через Интернет, не должен разрабатываться на Java какой-либо компонент приложения, или конкретное действие может быть выполнено только при одновременном действии двух игроков. Ограничения могут описывать количественные критерии, такие как требуемая производительность, время зарядки или время отклика для нескольких сайтов, а также качественные ограничения, такие как удобство обслуживания и удобство пользования.
Для максимальной ясности требование безопасности должно включать в себя по крайней мере следующие элементы:
a) роль действующего субъекта, который должен выполнить действие (кто);
b) желаемое действие по снижению риска (как);
c) момент, в который действие должно быть выполнено (когда);
d) где это действие должно быть выполнено (где);
e) информация, затрагиваемая этим требованием (что);
f) риск или источник риска, к которому относится это требование безопасности (почему).
Точно так же, как МОБП может быть представлено в графическом виде (см. ИСО/МЭК 27034-1:2011, рисунок 7), общие или высокоуровневые требования безопасности должны генерировать набор более конкретных требований.
Чтобы ускорить разработку, требование безопасности, разработанное во время реализации проекта приложения, может быть заменено эквивалентным требованием безопасности (снижающим тот же риск до приемлемого для проекта уровня), который уже присутствует в НСО. Библиотека МОБП организации содержит информацию, связывающую риски, требования и меры обеспечения безопасности [см. ИСО/МЭК 27034-2:2015 (пункт 5.5.7)].
В ходе разработки программного обеспечения проверка выполнения требований часто вызывает затруднения. Гораздо проще проверить, что соблюдены требования безопасности приложения. Для достижения каждого требования выбирается одно или несколько МОБП, как приведено на рисунке 3. Проверка правильности реализации этих МОБП гарантирует выполнение требования.
6.2.6.7 Определение целевого уровня доверия приложения
После того, как анализ рисков безопасности приложения завершен, а требования безопасности определены и проверены, целевой уровень доверия приложения должен быть идентифицирован с использованием библиотеки МОБП организации. Эта идентификация должна быть выполнена путем сравнения требований к безопасности, разработанных для приложения, с требованиями безопасности, перечисленными в библиотеке МОБП организации. Когда два требования безопасности почти идентичны (снижение одного и того же риска безопасности до одного и того же приемлемого уровня), можно заменить требование безопасности, определенное для приложения, на то, которое присутствует в библиотеке МОБП. Это гарантирует, что схожие требования безопасности всегда будут выполняться одинаковыми МОБП.
Если требование безопасности, определенное для приложения, не имеет эквивалента в библиотеке МОБП, запрос МОБП, который может включать в себя предложение МОБП, должен быть отправлен в группу НСО посредством процесса "Мониторинг и проверка НСО" [см. ИСО/МЭК 27034-2:2015 (пункт 5.4.6)].
Как только все требования безопасности, определенные для приложения, сопоставлены с теми, которые присутствуют в библиотеке МОБП, идентификатором требуемого целевого уровня доверия приложения для этого приложения будет уровень доверия приложения, который включает в себя как минимум все требования безопасности.
Затем проектная группа приложения должна подготовиться к передаче приложения владельцу для утверждения:
a) списка рисков безопасности и связанных с ними последствий, оцененных для данного проекта приложения;
b) списка требований безопасности для адекватной минимизации этих угроз безопасности;
c) уровня доверия приложения, включающего в себя МОБП, отвечающие требованиям безопасности, которые должны быть выполнены для этого приложения.
Проектная группа должна представить эту и другую вспомогательную информацию таким образом, чтобы помочь владельцу приложения принять обоснованное решение.
Пример - Группа может показать связи между рисками/требованиями безопасности, МОБП и затратами в табличной или графической форме, чтобы помочь владельцу приложения понять последствия и стоимость снижения каждого риска до приемлемого уровня и утверждения целевого уровня доверия приложения.
6.2.6.8 Принятие владельцем приложения
Владелец приложения несет ответственность за принятие остаточных рисков, связанных с определенным приложением, после их оценки. Данный этап соответствует этапу "принятие риска информационной безопасности" в рамках процесса менеджмента рисков, приведенного в ИСО/МЭК 27005.
Владелец может сделать это двумя способами:
a) утвердив целевой уровень доверия приложения на шаге 2 ПМБП;
b) утвердив результаты шага 5 ПМБП, в котором измеряется фактический уровень доверия приложения и сравнивается с целевым уровнем доверия приложения. Владелец приложения может прибегнуть к этому шагу в любое время.
Для дополнительного подтверждения владелец приложения может потребовать выполнения этого шага внешней группой, осуществляющей верификацию.
Ниже приведен пример остаточного риска, который может быть принят владельцем приложения.
Пример - Разрешить функцию "запомнить меня" на странице входа в приложения, используемые внутренними пользователями.
В приведенном выше примере владелец приложения подтверждает, что уровень риска, связанный с функцией "запомнить меня" для внутренних приложений, приемлем. Функция "запомнить меня" представляет такие риски, как несанкционированный доступ к приложению, если злоумышленник получит физический доступ к разблокированной рабочей станции жертвы. Владелец приложения может принять этот риск, учитывая, что вероятность такого несанкционированного физического доступа во внутреннем офисе организации невысока.
После того, как владелец принял остаточные риски, проектная группа берет на себя ответственность за достижение целевого уровня доверия приложения путем внедрения соответствующих МОБП на соответствующих этапах жизненного цикла.
Подписаться на обновления