---

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

---

Задание 1. Анализ иерархии нормативно-правовых актов

Схема соподчиненности документов:

Международный уровень:

· Конституция РФ (ст. 15 — общепризнанные принципы и нормы международного права)
· Международные договоры РФ
· Международные стандарты (ISO/IEC, IEEE)

Федеральный уровень:

· Федеральные законы: № 162-ФЗ «О стандартизации», № 184-ФЗ «О техническом регулировании», № 152-ФЗ «О персональных данных», № 149-ФЗ «Об информации»
· Указы и распоряжения Президента РФ
· Постановления и распоряжения Правительства РФ (в т.ч. перечни стандартов к техрегламентам)
· Приказы Минцифры России, ФСТЭК России, ФСБ России

Отраслевой уровень:

· Национальные стандарты: ГОСТ, ГОСТ Р
· Предварительные национальные стандарты (ПНСТ)
· Своды правил (СП)
· Отраслевые стандарты и методические рекомендации

Уровень предприятия:

· Стандарты организации (СТО) разработчика ПО
· Локальные акты IT-отдела: регламенты разработки, политики информационной безопасности, инструкции по делопроизводству

---

Задание 2. Работа с ФЗ-162 «О стандартизации»

Таблица. Столбцы: «Принцип (ст. 4 ФЗ-162)» | «Значение для разработчика ИС»

Принцип Значение для разработчика ИС
Добровольность применения Разработчик сам решает, использовать ли ГОСТ на оформление документации. Но если ПО поставляется в госструктуру, стандарт может стать обязательным через условие госконтракта.
Открытость обсуждения проектов стандартов Можно влиять на будущие требования: например, предложить включить в проект ГОСТ поддержку отечественного формата электронной подписи, если он нужен вашему продукту.
Применение международного стандарта как основы Вместо изобретения собственного протокола обмена данными между микросервисами разумнее взять за основу OpenAPI — это снизит затраты на интеграцию и документацию.
Недопустимость препятствования производству Введение нового требования по шифрованию не должно заставлять переписывать весь продукт за один день — нужен разумный переходный период.
Преемственность и непротиворечивость Новый стандарт не должен конфликтовать с уже действующими. Например, обновлённый ГОСТ по защите ПДн не может отменять требования ФЗ-152.
Эффективность и целесообразность Стандарт должен решать реальную проблему, а не создавать бюрократию. Внедрение ГОСТ ради галочки увеличивает срок разработки без пользы для продукта.

---

Задание 3. Анализ ГОСТ Р 57580.1-2017, раздел 7

Базовые требования к защите информации при проектировании и разработке ПО для банков и финтеха:

1. Разделение сред разработки, тестирования и промышленной эксплуатации. Код не должен попадать в продуктив напрямую из среды разработчика. Каждый переход — через контролируемую процедуру с проверкой.
2. Контроль версий и журналирование доступа к коду. Все изменения фиксируются в Git, доступ к репозиторию — по минимальным привилегиям, каждая операция логируется.
3. Обязательный анализ кода на уязвимости перед релизом. Статический анализ (SAST) ищет проблемы в исходниках, динамический (DAST) — в работающем приложении.
4. Безопасное кодирование. Защита от SQL-инъекций, XSS, CSRF, небезопасной десериализации, слабой криптографии.
5. Управление уязвимостями и обновлениями. Регулярный мониторинг CVE для используемых библиотек, своевременное обновление зависимостей.
6. Контроль целостности ПО. Проверка хеш-сумм дистрибутивов, подпись релизов, защита от подмены компонентов.

---

Задание 4. Коды ОКПД 2

Таблица. Столбцы: «Объект» | «Код ОКПД 2» | «Наименование категории» | «Пояснение выбора»

Объект Код Наименование Пояснение
Разработка мобильного приложения под iOS 62.01.11.000 Услуги по проектированию и разработке прикладного ПО Это процесс создания уникального ПО под конкретного заказчика. Код охватывает весь цикл: анализ требований, написание кода на Swift, тестирование, передачу готового продукта.
Услуги по управлению ИК-инфраструктурой 62.03.11.000 Услуги по управлению сетями Речь идёт о процессе эксплуатации: мониторинг, администрирование, диагностика сетей заказчика. Это не создание нового продукта, а управление существующей инфраструктурой.
Базы данных и информационные ресурсы 58.29.11.000 Системы операционные на электронном носителе Если продаётся готовый продукт или лицензия на доступ к базе — это раздел 58. Если же база создаётся на заказ — применяется раздел 62.

Важно: раздел 62 — это процессы (создание, модернизация), раздел 58 — готовый продукт или результат (лицензирование, продажа доступа).

---

Задание 5. Структура раздела ТЗ для ГБУ «Городской архив»

Таблица. Столбцы: «№» | «Подраздел ТЗ» | «Пример требования» | «Обоснование»

№ Подраздел Пример требования Обоснование
1 Характеристики объекта автоматизации «Портал должен обеспечивать приём запросов от граждан через форму обратной связи и автоматическое формирование уведомления о статусе обработки запроса». ФЗ-59 «О порядке рассмотрения обращений граждан»; ГОСТ 34.602-89.
2 Требования к функциям системы «Система должна обеспечивать полнотекстовый поиск по оцифрованным документам с фильтрацией по году, типу документа и фонду». ГОСТ Р 7.0.97-2016; внутренние регламенты архива.
3 Требования к защите ПДн «Все персональные данные граждан (ФИО, адрес, паспортные данные) должны храниться в зашифрованном виде. Ключи шифрования — в аппаратном модуле, сертифицированном ФСБ России». ФЗ-152 ст. 19; Приказ ФСБ России № 378.
4 Требования к надёжности «Время восстановления после сбоя — не более 4 часов. Ежедневное резервное копирование с хранением копий за последние 30 дней». ГОСТ Р ИСО/МЭК 27002-2021; ФЗ-152 ст. 19 ч. 2 п. 7.
5 Требования к эргономике «Интерфейс портала должен соответствовать требованиям доступности для слабовидящих: альтернативный текст для изображений, навигация с клавиатуры, контрастность не ниже 4.5:1». ГОСТ Р 52872-2019; ФЗ-419 «О социальной защите инвалидов».
6 Требования к интеграции «Интеграция с ЕСИА для авторизации граждан должна осуществляться по протоколу SAML 2.0 с использованием отечественных криптоалгоритмов ГОСТ 34.10-2018». Постановление Правительства РФ № 2814-р; методические рекомендации Минцифры.
7 Требования к документированию «Комплект документации должен включать: руководство администратора, руководство пользователя, программу и методику испытаний — в соответствии с ГОСТ 19.101-77». ГОСТ 34.602-89; ЕСПД (Единая система программной документации).
8 Требования к патентной чистоте «Все используемые компоненты должны иметь открытую лицензию (MIT, Apache 2.0) либо быть разработаны на основе отечественных ГОСТ, исключая выплаты иностранным правообладателям». ФЗ-162 «О стандартизации»; ФЗ-184 «О техническом регулировании».
9 Требования к сохранности информации «Сканы документов должны храниться в формате PDF/A с метаданными по ГОСТ Р 7.0.97-2016. Срок хранения — не менее 100 лет с периодической проверкой целостности». ГОСТ Р ИСО 13008-2015; ФЗ-125 «Об архивном деле».

---

Контрольные вопросы

1. Чем технический регламент отличается от национального стандарта?
Технический регламент — обязательные требования безопасности на уровне закона. Национальный стандарт — добровольные характеристики качества и методы проверки. Регламент отвечает на вопрос «что должно быть безопасно», стандарт — «как это проверить и каким должно быть качество».

2. Какой орган регулирует стандартизацию в РФ?
Росстандарт (Федеральное агентство по техническому регулированию и метрологии).

3. Что такое «Белый список» стандартов?
Перечень ГОСТов, применение которых на добровольной основе обеспечивает соблюдение требований конкретного технического регламента.

4. Как ПНСТ влияет на внедрение новой технологии в корпоративную ИС?
ПНСТ — это «черновик» стандарта, который можно применять до утверждения. Для разработчика это возможность начать внедрение раньше, но с риском, что финальная версия будет отличаться.

5. Кто может разрабатывать национальные стандарты в инициативном порядке?
Любое заинтересованное лицо: компания, общественная организация, технический комитет по стандартизации или отдельный специалист.