Обучение ППОД v6

1.

Процессы эксплуатации и
развития Платформы
поддержки основной
деятельности
www.at-consulting.ru

2.

Цели создания ППОД
• Создание условий для повышения операционной эффективности
функциональных подразделений Банка России
• Выполнение требований нормативных документов по обеспечению
информационной безопасности Банка России для прикладного
программного обеспечения, функционирующего на ППОД
• Предоставление сервисов по разработке прикладного программного
обеспечения по функциональным направлениям деятельности
подразделений Банка России, операциям наличного денежного
обращения, учету проверок и внутреннему аудиту, ведению
информации об административных правонарушениях,
предоставления аналитической информации по запросам
пользователей с использованием смежных систем и прикладных
платформ
• Повышение качества и скорости разработки ИТ-решений
• Создание условий для повышения скорости внедрения изменений
www.at-consulting.ru
2

3.

Структура ППОД
Сервисные
подсистемы
Приложение
«Тьюринг»
Генерация
данных
Компонент
«Тесла»
Управление
и
мониторинг
ППОД
Приложение
«Эйлер»
Интеграцио
н-ная шина
«Лейбниц»
Поиск и
индексация
Приложение
«Пифагор»
Формы и
интерфейсы
«Эвклид»
Прикладная
логика
Ядро платформы
Компонент «Ньютон»
Управление жизненным
циклом приложений
Приложение
Компонент «Эйнштейн»
Исполнение сервисов и
приложений
«Кантор»
Хранение
документов
(IBM
FileNet)
Компонент
«Рентген»
Регистрация
событий и
авторизация
Хранилище данных платформы
www.at-consulting.ru
3

4.

Структура ППОД
• Приложения – часто изменяемые элементы,
выполняющие бизнес-функции
• Сервисные подсистемы (СПС) – технологические
элементы, предоставляющие общую функциональность
для разработки приложений. Состав СПС может
изменяться без больших изменений Платформы
• Компоненты Ядра – неотъемлемые технологические
элементы, выполняющие основные функции ППОД.
Изменение компонентов ядра, это изменение
Платформы в целом
www.at-consulting.ru
4

5.

Интегрированные и выделенные приложения
Интегрированные приложения – Приложения,
разработанные с использованием микросервисного
подхода, полностью исполняющиеся в компоненте
«Эйнштейн» (контейнерная платформа)
Выделенные приложения – Приложения, исполняющиеся
полностью или частично на выделенных виртуальных
машинах ЧОБР, СТР Полигон в рамках пула ресурсов ППОД.
www.at-consulting.ru
5

6.

Основные регламенты и руководства
Регламенты
• ЦБРФ.62.0.39676.ИВ.02 Внутренний регламент эксплуатации ппод
(для администраторов)
• ЦБРФ.62.0.39676.ИВ.03 Регламент развития ппод
• ЦБРФ.62.0.39676.ИВ.04 Регламент подключения пользователей и
эксплуатационного персонала
Руководства
• ЦБРФ.62.0.39676.И3.02 Руководство разработчика
• ЦБРФ.62.0.39676.И7 Руководство администратора информационной
безопасности
Шаблоны документов для приложений (слайд 9)
www.at-consulting.ru
6

7.

Общие требования к приложениям
• Приложение должно использовать сервисы
аутентификации и идентификации в составе компонента
«Рентген» (Blitz SSO)
• Приложение должно использовать сервисы авторизации
в составе компонента рентген ППОД(ABAC)
• Сбор событий информационной безопасности
приложения ППОД должен осуществляться с помощью
отправки на сервис компонента «Рентген» (отдельный
Input в Splunk)
• Сбор событий безопасности для выделенного
приложения может осуществляться помощью пересылки
содержимого файла /var/log/security/audit.Log в средств
сбора событий безопаности
www.at-consulting.ru
7

8.

Требования к выделенным приложениям
• Для виртуальных машин выделенных приложений
необходима проверка наличия:
• установленного агента антивирусного ПО
• установленного rsyslog с настройкой отправки системных
сообщений
• наличия синхронизации времени с центральным сервером.
• Доступ к виртуальным машинам под административной
учётной записью должен осуществляться через СКДПУ
• Должны быть настроены правила межсетевого экрана
для сети и адресов приложения на облачной
вычислительной платформе МСЭ ЧОБР/СТР Полигон
• Должна быть обеспечена безопасность виртуальной
машины с использованием vgate ЧОБР/СТР Полигон
www.at-consulting.ru
8

9.

Документы приложений
Документы, разрабатываемые в ходе создания приложения ППОД
Название
Техническое задание
(карточка приложения)
Спецификация
Описание приложения
Назначение
Содержит требования к реализации функциональных и
нефункциональных требований к приложению
Руководство пользователя
Руководство для бизнес-пользователей приложения
Руководство администратора
Описание операций, отличных от типовых операций с
приложением, осуществляемых эксплуатационным
персоналом ППОД (в том числе, администратора ППОД)
Программа и методика
испытаний
Программа опытной
эксплуатации
Описание методики проверки, шаги проверок и ожидаемые
результаты
Описание подхода к проведению опытной эксплуатации,
перечень операций
www.at-consulting.ru
Компиляция из пояснительных записок по ГОСТ 34 и 19,
включая описание реализации требований по безопасности
9

10.

Интеграционное взаимодействие
• Взаимодействие с КХД/ЕХД и их сервисами производится
напрямую
• Взаимодействие внутри ППОД (СПС Эйлер)
• Приложение ППОД – Приложение ППОД
• Взаимодействие с другими Платформами (СПС Эйлер ПИС)
• С приложением в другой Платформе
• С приложением в другой Платформе, не имеющим
подключения к ПИС (через СДС)
• Взаимодействие требующее шифрования
www.at-consulting.ru
10

11.

Интеграционное взаимодействие
Взаимодействие
внутри ППОД
Приложение
ППОД
Отправитель
Приложение ППОД ->
Система во внешней
платформе
Приложение
ППОД
Отправитель
СПС Эйлер:
Прием, обработка, отправка
Интеграционный сценарий
www.at-consulting.ru
Приложение
ППОД получаетль
СПС Эйлер:
Прием, обработка, отправка
Интеграционный сценарий
Система во внешней платформе ->
Приложение ППОД
Система во
внешней
платформе
Входной адаптер
ПИС (Платформа
интеграционных
сервисов)
ПИС (Платформа
интеграционных
сервисов)
Выходной адаптер
Система во
внешней
платформе
СПС Эйлер:
Прием, обработка, отправка
Интеграционный сценарий
Приложение
ППОД получаетль
11

12.

Процесс изменения ППОД и приложений
Описан в ЦБРФ.62.0.39676.ИВ.03 Регламент развития ППОД
Разные жизненные циклы для:
• Компонентов ядра ППОД
• СПС ППОД
• Приложений ППОД
www.at-consulting.ru
12

13.

Изменение приложений
1.
Создание и согласование документов на разработку нового или на изменение
существующего приложения;
2.
Создание/редактирование карточки на разработку нового или на изменение
существующего приложения;
3.
Разработка нового или реализация доработок существующего приложения в ЗР
с внутренним тестированием;
4.
Создание и согласование комплекта эксплуатационных документов для
приложения, а также документации, необходимой для осуществления
тестирования;
5.
Версия ПО приложения (релиз) в виде архива с исходным кодом и окружением
разработки передается в ЗТ;
6.
Тестирование нового или доработанного приложения, в том числе проведение
предварительных испытаний, опытной эксплуатации и приемочных испытаний;
7.
Перенос приложения в ЗПЭ. Развёртывание исполняемого модуля приложения
в ЗПЭ производится из уже готового контейнера (виртуальной машины);
8.
Ввод в эксплуатацию нового или доработанного приложения;
9.
Вывод приложения из эксплуатации.
www.at-consulting.ru
13

14.

Особенности изменения приложений
• Релизы формируются разработчиками в ЗР
• Релизы переносятся в ЗТ и ЗПЭ автоматизированными
процедурами
• Разработчик не имеет доступа в ЗТ и ЗПЭ
• Формирование релизов – штатная, частая операция
• Каждый релиз проходит проверку SonarQube, PTAI
www.at-consulting.ru
14

15.

Изменение СПС
1.
Создание и согласование документов на разработку новой или изменение
существующей СПС;
2.
Создание/редактирование карточки новой или существующей СПС;
3.
Разработка новой или реализация доработок существующей СПС в ЗР;
4.
Определение перечня зависимых приложений, сервисов, СПС и компонент
ядра;
5.
Уточнение и согласование комплекта эксплуатационных документов для СПС, а
также документации, необходимой для осуществления тестирования;
6.
Перенос СПС в ЗТ;
7.
Тестирование новой или доработанной СПС в ЗТ, в том числе проведение
предварительных испытаний, опытной эксплуатации и приемочных испытаний;
8.
Перенос новой или доработанной СПС в ЗПЭ;
9.
Ввод в эксплуатацию новой или доработанной СПС;
10. Вывод СПС из эксплуатации.
www.at-consulting.ru
15

16.

Особенности изменения СПС
СПС влияет на приложения, которые её используют
Новые версии СПС требуют развертывания сегментов
разработки в ЗР ППОД
Новые версии СПС вводятся в эксплуатацию
одновременно с предыдущей, действующей версией.
После периода перехода приложений на использование
новой версии, старая версия СПС выводится из
эксплуатации
www.at-consulting.ru
16

17.

Изменение компонентов Ядра
1.
Задание на изменение ядра ППОД;
2.
Разработка нового или реализация доработок существующего компонента
ядра ППОД в ЗР;
3.
Определение перечня зависимых приложений, сервисов, СПС и компонент
ядра;
4.
Уточнение и согласование комплекта эксплуатационных документов для
ядра ППОД, а также документации, необходимой для осуществления
тестирования;
5.
Перенос измененного компонента ядра ППОД в ЗТ;
6.
Тестирование измененного ядра ППОД в ЗТ, в том числе проведение
предварительных испытаний, опытной эксплуатации и приемочных
испытаний;
7.
Развертывание измененного ядра ППОД в ЗПЭ;
8.
Ввод в эксплуатацию измененного компонента ядра ППОД.
www.at-consulting.ru
17

18.

Особенности изменения Ядра ППОД
Изменения Ядра могут быть:
• Не значительные для архитектуры, не влияющие на
ЖЦ приложений, например минорные обновления
компонентов, корректировка настроек, политик
• Значительные изменения, затрагивающие ЖЦ,
принципы разработки, состав документации и др.
www.at-consulting.ru
18

19.

Особенности изменения Ядра ППОД
• Не значительные изменения
• Для тестирования разворачиваются копии компонентов в ЗР,
проводится тестирование в составе существующей ЗР
• Выполняется развертывание в ЗТ, ЗПЭ
• Значительные изменения
• При разработке новой версии Ядра ППОД в ЗР ППОД должны
разворачиваться сегменты ППОД, эмулирующие работу всех
зон (ЗР, ЗТ, ЗПЭ)
• При разработке Ядра ППОД должны быть разработана
процедура миграции текущей версии Ядра ППОД на новую, с
учетом переноса приложений и СПС
• При испытаниях Ядра ППОД должны проводится
комплексные испытания. Должны проверяться механизмы
ядра на примере существующих приложений и СПС
(выборочно)
www.at-consulting.ru
19

20.

Порядок экспертизы

21.

Анализ документации приложений
В Функциональных требованиях, необходимо проверить:
• Наличие ссылок на основные документы ППОД, содержащие
типовые требования
• Требования бизнеса по авторизации и наличие бизнес-правил
доступа
• Наличие требований по делегированию управления доступом
бизнес-пользователям
• Источники данных, интеграционные задачи, потоки данных,
использование внешних сервисов-может повлиять на состав
документов, содержащих технические требования (ТЗ на
приложение, ТЗ на ИС, карточка исц ПИС)
www.at-consulting.ru
21

22.

Анализ документации приложений
В Техническом задании, необходимо проверить:
• Состав технических требований по интеграции с рентген
• Источники данных и требования к смежным системам
• Порядок ввода в действие и наличие внутреннего или
дополнительного тестирования, а также категории данных в разных
зонах
• Требования по подготовке тестовых данных
• Требования по архитектуре приложения
• Требования по фиксации событий ИБ
• Требования по разработке политик АБАК
www.at-consulting.ru
22

23.

Анализ документации приложений
В Технорабочем проекте, необходимо проверить:
• Выполнение вышеуказанных требований ТЗ
• Описание политик и правил
• Перечня фиксируемых событий
• Состав объектов защиты и их классификация
На стадии Испытаний, необходимо проверять:
• Наличие отчета о проверке PT Application Inspector,
• Настройки Компонента «Рентген» для приложения: АБАК, Blitz,
Splunk (выполняется с использованием контроллеров эксплуатации
проверка)
• Также анализируются настройки развертывания и подключения.
www.at-consulting.ru
23

24.

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

25.

Документация мигрированных приложений
Организация информационно-технического взаимодействия
приложений ППОД с информационными системами Банка России
не нарушает существующий уровень их информационной
безопасности.
Приложения ППОД используют унифицированные сервисы Компонента
«Рентген» Ядра ППОД для выполнения требований по обеспечению
информационной безопасности:
аутентификация с помощью технологии Single Sign On (SSO);
поддержка протокола HTTPS;
авторизация с помощью модуля ABAC.
Приложения ППОД используют унифицированные сервисы Компонента
«Тесла» Ядра ППОД для выполнения требований по обеспечению
информационной безопасности в части логирования действий,
совершенных бизнес-пользователями.
www.at-consulting.ru
25

26.

Документация мигрированных приложений
Требования к информационной безопасности Приложений предъявляются
в параграфе 4.2 «Требования по безопасности» документов «Техническое
задание»:
ЦБРФ.62.0.39676.ТЗ.П-Госказна;
ЦБРФ.62.0.39676.ТЗ.П-УКО.
В качестве требований предъявляется необходимость использования
унифицированных сервисов Компонентов «Тесла» и «Рентген» Ядра ППОД, а
так же необходимость доступа сотрудников Банка России под ролями бизнеспользователей с определенной бизнес-функцией. Так же в этом параграфе
приводится список документов в соответствии с которым пользователи ППОД и
эксплуатационный персонал должны работать с Приложениями.
Перечисленные выше требования к информационной безопасности
Приложений проверяются в проверках А.2.1 «Проверка авторизации
пользователя в Приложении» и Б.1 «Проверка требований к безопасности»
документов «Программа и методика испытаний»:
ЦБРФ.62.0.39676.ПМ.П-Госказна
ЦБРФ.62.0.39676.ПМ.П-УКО
www.at-consulting.ru
26

27.

Документация мигрированных приложений
Принципы разграничения доступа, описание ролевой модели, описание
компонентов регистрации событий и перечень регистрируемых событий
информационной безопасности приложений ППОД описываются в параграфе
3.2 «Решения по безопасности» документов «Описание приложений»:
ЦБРФ.62.0.39676.ПА.П-Госказна;
ЦБРФ.62.0.39676.ПА.П-УКО.
Так же в Приложении к документам «Описание приложений» приведены
идентификаторы элементов приложений ППОД.
www.at-consulting.ru
27