51
Рисунок 28. Настройка балансировщика нагрузки и горизонтальное
масштабирование
Вывод к главе 1
На основания рассмотренного материала выяснили, что для
сопровождения разработки и выкатывания программного обеспечения,
необходимо внедрять лучшие DevOps практики и инструменты для
эксплуатации и разворачивании системы. Самыми главными особенностями
этих процессов является то, что они встраиваются в структуру процесса
разработки продукта. Также для того, чтобы обеспечить упрощение подходов к
безопасности и соответствия требованим гос стандартов, необходимо применять
практики DevSecOps и также встраивать их в процесс разработки.
52
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для начала определимся с намеченной схемой построения
инфраструктуры, чтобы понять, какие подходы и инструменты будут
использоваться при разработке автоматизации развёртывания окружения.
Разработка в компании происходит по гибкой методологии Agile [1], это
значит, что процесс происходит итерационно, по спиральной модели. Поэтому
важно тестировать и непрерывно улучшать продукт с каждой итерацией.
Рисунок 29. Ожидаемая схема проекта
53
Для начала необходимо организовать виртуальное частное облако (Virtual
Private Cloud, VPC [6]), где будут располагаться внутренние сервисы.
Необходимо организовать разные подсети для различных задач: публичные и
приватные. В публичных сетях будут располагаться ресурсы, к которым
необходим доступ из интернета, такие, как бастион сервер и web-server Nginx. В
приватных сетях будут располагаться сервисы решения HAPICloud и те сервисы,
которые могут иметь связь с внешним миром через NAT и прокси-серверы.
Как видно, мы хотим использовать балансировщик в роли единой точки
входа, который будет распределять трафик HTTPS между NGINX серверами,
которые будут обеспечивать связь с сервисами HAPI, которые развёрнуты в ECS
[7] кластере. Главное требование к этому узлу состоит в устойчивости к
нагрузкам и отказам и в простоте горизонтального масштабирования, поэтому
будут использованы Auto Scaling группы, которые увеличивают количество
инстансов при повышении нагрузки, а также поднимают новые инстансы, если
старые отказали по тем или иным причинам. Для хранения данных, которые
используют сервисы, HAPICloud используется Amazon Relational Database
Service (RDS) PostgreSQL версии 10.6 [26].
Автоматизацией этого этапа развёртывания будут проходить в 2 этапа:
вначале с помощью Packer [27] подготовим запускаемые образы для web-
сервера Nginx, где будем собирать приложение Nginx из исходного кода при
помощи bash скриптов вместе с кастомными модулями, которые необходимо
использовать во время эксплуатации. Также будет использоваться Ansible [18]
для конфигурации и настройки Nginx [13]сервера.
Затем разворачивание инфраструктуры будет происходить c помощью
Terraform [22]. С его помощью в декларативной форме будут созданы
• VPC
• Указаны дата-центры, где будет разворачиваться окружение
• Network Load Balancer для распределения нагрузки
• Подсети
• Шлюз во внешнюю сеть
54
• Определение правил для входящего и исходящего трафика с
помощью Security Groups
• EC2 серверы
• RDS
В роли базы данных для хранения состояния Terraform [22], с которым
могут работать все участники процесса, будет использоваться Amazon S3 [23]
хранилище.
Автоматизация развёртывания приложений HAPICloud будет
происходить при помощи сервера интеграции TeamCity [17]. С его помощью
будет автоматически запускаться сборка и тестирование кода, подтягиваться
зависимости. Созданные в результате артефакты будут заворачиваться в Docker
[8] образы и отправляться в хранилище репозиторий Amazon Container Registry
[10], а затем запускать в Amazon Container Services [7].
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Методология процесса оценки риска для перемещения данных
разработана в соответствии с требованиями 6.1.2, 6.1.3, 8.2 и 8.3 стандарта ISO /
IEC 27001: 2013 [28] «Информационные технологии. Методы защиты. Системы
управления информационной безопасностью. Требования» и Политикой
информационной безопасности внутри компании Data Travel.
При оценке рисков компания придерживается следующих правил:
• Все сотрудники, подрядчики, консультанты, временные и другие
работники Data Travel и его дочерних компаний участвуют в процессах оценки
рисков.
• Данные политики рименимы ко всем активам персональных данных
(personally identifiable information, PII) и среде данных держателей карт.
• Для активов, которые не влияют на безопасность персональных
данных или данных о держателях карт, использование этой формальной
процедуры контроля изменений осуществляется по усмотрению руководства
Data Travel.
55
Определения и термины
ISM - Менеджер информационной безопасности
СУИБ - система управления информационной безопасностью, набор
политик, связанных с управлением информационной безопасностью или
рисками, связанными с ИТ, который обозначает проектирование, реализацию и
обслуживание согласованного набора политик, процессов и систем для
управления рисками для своих информационных активов.
Первый этап - это идентификация всех активов в области действия
СМИБ. Все активы, которые могут повлиять на конфиденциальность,
целостность и доступность данных держателя карты, должны быть
идентифицированы. Активы могут быть бумажными или электронными
документами, приложениями, базами данных, персоналом, компьютерным
оборудованием, комнатами или внешними службами. Для каждого актива Data
Travel должны быть определены владельцы активов - сотрудник или отдел,
ответственный за актив. Следующим шагом является выявление угроз и
уязвимостей, связанных с каждым активом Data Travel. Базовые угрозы и
уязвимости могут быть определены путем выбора из списка, включенного в
Таблицу оценки рисков. Владельцы активов могут определять дополнительные
угрозы и уязвимости в зависимости от контекста применения данного актива
(требования безопасности, бизнес-требования, правовые акты и т. д.)
Для каждого актива Data Travel должны быть определены владельцы
активов - сотрудник или отдел, ответственный за акт.
Последствия и вероятность
Следующим шагом является определение уровня Последствия (влияние
на Data Travel) в случае нанесения урона. Уровень последствий определяется
отдельно для каждой комбинации угрозы/уязвимости в соответствии со
следующей таблицей:
56
Таблица 3
Таблица угроз
После оценки последствий владельцы рисков идентифицируют
вероятность возникновения риска - вероятность каждой уязвимости для каждой
угрозы актива в соответствии со следующей таблицей:
Таблица 4
Вероятность возникновения риска
Вероятность
Числовое
соответствие
Описание
Низкий
1
Существующие меры безопасности
обеспечивают адекватный уровень
защиты. Появления новых инцидентов не
ожидается.
Уровень
последствий
Числовое
соответствие
Описание
Низкий
1
Утрата конфиденциальности, целостности или
доступности:
• не приведет к потере финансов,
• не будет нарушать юридические или
договорные обязательства,
• не повлияет на репутацию Data Travel.
средний
2
Утрата конфиденциальности, целостности или
доступности:
• приведет к несущественным
финансовым потерям
• или незначительные нарушения
правовых / договорных обязательств
• или окажет небольшое негативное
влияние на репутацию Data Travel.
Высоко
3
Утрата конфиденциальности, целостности или
доступности:
• приведет к значительным финансовым
потерям
• или серьезные нарушения правовых /
договорных обязательств
• или оказать негативное влияние на
репутацию Data Travel.
57
Вероятность
Числовое
соответствие
Описание
средний
2
Такие меры безопасности в среднем и в
большинстве случаев обеспечивают
достаточный уровень защиты. Появление новых
инцидентов возможно, но маловероятно.
Высоко
3
Существующие меры безопасности не
эффективны и не обеспечивают адекватный
уровень защиты. Появление новых инцидентов
в будущем возможно.
Критерии принятия рисков
Уровень риска автоматически рассчитывается путем сложения двух
значений. Уровни риска 2-4 являются приемлемыми. Уровень риска 5-6
недопустим и должен быть обработан.
Обработка рисков
Обработка рисков осуществляется в Таблице обработки рисков путем
копирования всех рисков, определенных как неприемлемые.
Для каждого неприемлемого риска следует выбрать один или несколько
методов обработки риска:
• Выбор элемента управления / нескольких элементов управления из
Приложения А стандарта ISO / IEC 27001 или определение других мер
безопасности для снижения риска.
• Передача риска третьему лицу - например, страховой компании
путем покупки страхового полиса.
• Предотвращение риска, например, путем прекращения рискованной
деятельности или пересмотра метода ее выполнения.
• Принятие риска, например, если затраты на реализацию мер
безопасности превышают убытки, вызванные реализацией риска.
Выбор процесса обработки риска осуществляется, исходя из приложения
A стандарта ISO / IEC 27001.
58
После принятия защитных мер в Таблице обработки рисков необходимо
оценить новый уровень вероятности и последствий, чтобы определить
эффективность защитных мер.
Владельцы рисков должны регулярно просматривать и обновлять
Таблицу оценки рисков и Таблицу обработки рисков в соответствии со способом
выявления новых рисков.
Пересмотр проводится не реже одного раза в год или при значительных
изменениях в организационной структуре, технологии, законодательстве,
бизнес-целях и т. д.
ISM готовит план обработки рисков, в котором описывается план
реализации выбранных мер безопасности. Если для конкретного риска не
определен владелец конкретного риска, генеральный директор является
владельцем риска и несет за него ответственность. ISM документирует оценку
риска и результаты обработки, а также любые последующие изменения в Отчете
об оценке риска и обработке риска.
ISM должен просмотреть документ и вносить изменения перед каждым
пересмотром существующей оценки риска, если это необходимо, не реже одного
раза в год.
Следующие критерии используются для оценки эффективности этого
документа:
• количество инцидентов, которые не были учтены при оценке риска;
• количество риска, который не был обработан должным образом;
• количество ошибок в процессе оценки и лечения рисков возникло из-
за нечеткого определения ролей и обязанностей или других причин.
Ожидаемые риски
Следующие риски, выявленные в ходе оценки рисков, применимы к
архитектуре:
• Распределенная атака типа «отказ в обслуживании» (высокая)
• AWS не может предоставить сервис (высокий)
59
• Aiven не в состоянии предоставить услугу (средний)
• MongoDB Atlas не в состоянии предоставлять услуги (средний)
• Кража данных аккаунта AWS (высокий)
• Кража данных аккаунта Aiven (средний)
• Кража данных аккаунта MongoDB Atlas (средний)
• Бэкдор в исходном коде (низкий)
• Базовый образ докера с вредоносными программами (средний)
Автоматизированное управление
• Статический анализ кода на SonarQube
• Сборка на TeamCity
• Запускать юнит-тесты, интеграционные и нагрузочные тесты на
TeamCity
• Развертывание в среде DEV AWS из TeamCity
• Проверка образов Docker на наличие уязвимостей с помощью trivy
• Проверка соответствия PCI на WAZUH (среда PROD)
• Запуск эталонных тестов CIS на AWS Security Hub (среда PROD)
Ручное управление
• Обзор кода в Bitbucket
• Развертывание в среде DEMO AWS из TeamCity
• Развертывание в среде PROD AWS из TeamCity
• Разрешение на выпуск
• Мониторинг логов развернутого приложения в Кибане
Контроль обеспечения
• Ведущий разработчик: обзор кода и покрытие кода модульными и
интеграционными тестами
• QA инженер: функционал, интеграция и нагрузочное тестирование
• ISM: проверка на уязвимости
60
• Ведущий разработчик: выпустить релиз
• Инженер поддержки: отслеживание предупреждений в
производственной среде
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В рамках программ Data Travel GDPR, CCPA, ISO / IEC 27001 и PCI
Compliance важно наличие официальной Политики информационной
безопасности. Целью этой политики является обобщение ключевых инициатив в
области безопасности, которые связаны с дальнейшими политиками и
стандартами.
Документы, на которые опирается политика:
• Стандарт ISO / IEC 27001, пункты 5.2 и 5.3
• Процедура контроля изменений
• Политика набора разработчиков
• Политика управления поставщиками услуг
• Процесс разработки программного обеспечения
• Оценка риска и методология обработки риска
• Процедура управления инцидентами
• Стандарт безопасности данных индустрии платежных карт
• Контрольный список закаливания
• Регламент (EU) 2016/679 Европейского парламента и Директива
95/46 / EC (Общие положения о защите данных)
• Калифорнийский закон о защите прав потребителей от 2018 года
(Civ. 1.81.5 -1798.100-1798-199)
Основная терминология
Конфиденциальность - характеристика информации, с помощью
которой она доступна только уполномоченным лицам или системам.