Описание проектной работы 7 спринта

В этом уроке вы познакомитесь с проектной работой седьмого спринта. Это поможет вам оценить её сложность и распланировать своё время.
🔍 Обратите внимание: вам не нужно выполнять эти задания прямо сейчас. Можете пропустить этот урок и перейти к изучению теории. В конце спринта будет отдельный урок для сдачи проекта: там мы повторим задания и дадим форму, через которую нужно отправить решение.
В этот раз вы будете работать над кейсом компании PropDevelopment.

О компании

PropDevelopment — это крупная строительная компания. Она входит в топ-3 застройщиков в стране и продолжает активно развиваться.
PropDevelopment предоставляет клиентам услуги, которые связаны с покупкой недвижимости и обслуживанием жилых комплексов. В основном компания работает с частными клиентами. Их можно разделить на две категории:
  • Потенциальные покупатели жилья. Их мы будем называть «клиенты».
  • Собственники, которые приобрели жильё у компании. Их так и будем называть — «собственники».
Клиентам компания предлагает такие IT-продукты:
  • Онлайн-витрина для подбора и бронирования недвижимости из фонда PropDevelopment.
  • Онлайн-тур — приложение, которое позволяет клиентам осмотреть жильё без посещения объекта недвижимости.
  • Онлайн-сделка — приложение, которое позволяет проводить сделки по покупке недвижимости онлайн.
Для собственников компания разработала мобильное приложение, которое упрощает взаимодействия с управляющей компанией. В приложении можно:
  • Оплачивать услуги ЖКХ.
  • Получать информацию от управляющей компании.
  • Следить за текущим и капитальным ремонтом. Собственники могут просматривать актуальные данные о запланированных работах и изучать историю проведённых работ.
  • Управлять «Умным домом». Например, можно управлять автоматикой в жилом помещении и на этажах, а ещё контролировать устройство, которое запирает квартиру.

1. Текущее состояние архитектуры

У компании доменная структура. Каждый домен отвечает за часть бизнеса и состоит из ряда продуктовых команд. Всего в PropDevelopment четыре домена:
  • Группа сервисов для продаж. Сюда входит пять приложений: витрина продаж, client-tour-app (приложение для онлайн-тура), client-mart-app (приложение для онлайн-сделки), client-crm-app (система для управления клиентскими данными) и client-mart-estate-app (приложение для управления данными о недвижимости). У всех приложений, кроме витрины, есть собственная база данных.
  • Группа сервисов ЖКУ. Они отвечают за предоставление услуг собственникам. Сюда входит витрина, tenant-core-app (сервис для предоставления услуг) и его БД, а также CRM, которая управляет данными о собственниках, и её БД.
  • Финансы. В этот домен входит система финансового учёта — accountant-service-1, а также её БД и служба каталогов.
  • Дата — группа сервисов, которые отвечают за обработку данных. Сюда входит хранилище, BI и отчётность.
Так выглядит диаграмма контейнеров компании в модели C4:
Группа сервисов для клиентов — самая сложная. Здесь такая логика взаимодействия с пользователем:
  • Монолитное приложение позволяет частным клиентам осуществлять подбор и бронирование недвижимости.
  • Каждое бронирование недвижимости может сопровождаться осмотром. Это может быть офлайн-посещение или онлайн-тур. Результаты осмотра фиксируются в IT-системах. При бронировании клиент указывает контактные данные — Ф. И. О., телефон и электронную почту. Ещё он может заполнить расширенную форму. Данные из расширенной формы далее используются при проведении онлайн-сделки.
  • По результатам бронирования клиент может принять решение о покупке квартиры. Для этого реализована функциональность онлайн-сделки. Это сложный технический и юридический процесс, который клиент может провести через IT-системы PropDevelopment. Для этого компания реализовала интеграцию с госорганами, которые отвечают за определённые этапы.

2. Инфраструктура

Большинство IT-продуктов развёрнуты на собственных серверах. Часть продуктов развёрнуты в гибриде. Для временного расширения мощностей на этапах доработки и тестирования команды могут использовать облачные ресурсы и управляемые сервисы.
Сервисы компании развёрнуты в приватном облаке, имеется собственный ЦОД и используются мощности, арендованные у облачного провайдера.
Для всех баз данных выполняется резервное копирование данных на глубину, которая необходима для восстановления данных.
Доступ в систему для внешних пользователей (клиентов и собственников) осуществляется через межсетевой экран (firewall).

3. Структура команд

Продуктовая команда состоит из двух команд: функциональной и операционной.
Функциональная команда отвечает за разработку, развитие и поддержку IT-продуктов. Каждая функциональная команда состоит из:
  • владельца продукта,
  • бизнес-аналитиков,
  • разработчиков,
  • инженеров по эксплуатации.
  • DevOps-инженера.
Операционная команда — использует IT-продукты, разработанные продуктовой командой, в операционной деятельности компании. Операционная команда состоит из менеджеров. Они обеспечивают эффективное использование и развитие продуктов.
Специалист по ИБ один на всю компанию. Недавно были изменения в составе руководителей IT-команд, из-за чего нарушился процесс передачи информации между командами. В какой-то момент стало понятно, что специалисту по ИБ передают не все решения и изменения.

4. Проблемы и потребности бизнеса

Глобально у компании две проблемы.
Нарушен контроль данных. Есть несколько точек регистрации нового клиента, координации между этими точками нет. Внутренние потоки данных между IT-продуктами контролируются не системно. Ограничения по передаваемым данным в основном обусловлены бизнес-процессами между взаимодействующими IT-продуктами. Со стороны систем обработки данных нет ограничений на доступ к данным.
Есть проблемы с API партнёров. Партнёры — это системы управляющих компаний, которые позволяют собственникам оплачивать ЖКУ и следить за информацией о доме. Системы PropDevelopment используют API управляющих компаний без единых политик по безопасности и без системного контроля за передаваемыми данными. В ходе интеграций команды разработки не раз замечали, что:
  • Контракты API содержат категории данных, которые явно предоставляют персональные данные.
  • Некоторые контракты позволяют внешним пользователям выполнять действия и получать данные, к которым у них не должно быть доступа. Например, партнёр из одной управляющей компании может увидеть или изменить данные клиентов и жилищных комплексов, которые относятся к другой компании.
При этом компания собирается активно развивать сервисы для покупателей и жильцов. В том числе — за счёт партнёрских сервисов.
В итоге PropDevelopment собирается провести комплексный аудит безопасности. Сейчас компания готовится к этому мероприятию. Аудит безопасности поможет решить описанные проблемы и закрыть потребности бизнеса:
  • Повысить уровень удовлетворённости клиентов. Компания столкнулась с жалобами клиентов: они видят в приложении ошибки, когда заходят в личный кабинет. Там иногда могут отображаться данные другого клиента — например, другое Ф. И. О. Аудит безопасности позволит найти источник проблемы и устранить её.
  • Компания не может расширять направление обработки данных. Компания активно накапливает данные, которые можно «заставить работать», — извлечь из данных знания и реализовать новые сервисы. PropDevelopment планирует реализовать новые сервисы на базе BI-, ML- и AI-технологий. Сейчас проблема управления и хранения потоков данных блокирует реализацию новых продуктов, основанных на данных.
  • Отреагировать на инциденты и рыночные изменения. Недавно у конкурента произошла утечка данных, которая активно обсуждалась в СМИ. Руководство PropDevelopment обеспокоено. Аудит безопасности должен помочь компании предотвратить подобные инциденты.
  • Проверить соответствие требованиям законодательства. IT-ландшафт PropDevelopment активно развивался: появлялись новые интеграции с поставщиками услуг для продажи недвижимости и новые услуги для жильцов. Сейчас нет уверенности в том, что все текущие бизнес-процессы компании соответствуют законодательным нормам. Аудит позволит проверить, выполняет ли компания требования законодательства РФ, и предотвратить возможные штрафы.

Как подготовиться к работе

Подготовьте репозиторий, куда вы будете загружать решения заданий:
  1. Проект этого спринта вы будете сдавать в Git-репозитории. Создайте публичный репозиторий в GitHub или GitLab. Назовите его «architecture-propdevelopment».
  2. Проект состоит из пяти заданий. Решение каждого задания нужно будет залить в отдельную директорию. Создайте в репозитории пять директорий и назовите их «Task1», «Task2», «Task3», «Task4» и «Task5».
  3. Чтобы ревьюеру было проще проверять вашу работу, а вам отслеживать изменения на разных итерациях, загрузите файлы в свой репозиторий и сделайте пулл-реквест. На ревью нужно отправить ссылку на пулл-реквест.
Если репозиторий готов, можно приступать к заданиям!

Задание 1. Разработка проверочного листа по безопасности данных

Первым делом нужно разработать проверочный лист по безопасности данных. Сейчас это ключевая проблема компании и самое уязвимое место.
Чтобы создать документ, выполните четыре шага.
  1. Проанализируйте диаграмму и описание системы PropDevelopment
Классифицируйте типы данных, с которыми работает компания, по стандартам ISO/IEC 27001 и 27002. Распределите их по четырём категориям:
  • публичные данные,
  • внутренние данные,
  • конфиденциальные данные,
  • секретные данные.
  1. Определите риски для каждой категории данных
В каждой категории данных могут существовать следующие риски:
  • утечка данных,
  • потеря данных,
  • искажение данных,
  • некачественные данные,
  • обесценивание данных.
  1. Объясните, почему именно этот риск актуален для указанной категории данных
  2. Дайте оценку каждому риску
В качестве шкалы используйте категории «незначительный-значительный-критический».
  1. Визуализируйте результаты анализа в виде mindmap
Для создания mindmap используйте draw.io. В центре разместите блок «Безопасность данных». От него протяните стрелочки и разместите следующий уровень — выделенные категории данных. На следующем уровне укажите, какие именно данные компании относятся к этой категории. Для каждого типа данных укажите риск и присвойте ему оценку. На последнем уровне объясните, почему вы оценили риск именно так.
Когда mindmap будет готов, загрузите его в директорию Task1 вашего репозитория.

Задание 2. Разработка и заполнение проверочного листа для бизнес-систем

Теперь вам необходимо составить проверочный лист безопасности для бизнес-систем.
Для этого:
  • Проанализируйте схему и описание системы. Идентифицируйте системы и изучите характер их работы с точки зрения безопасности.
  • Выберите, какие разделы включить в проверочный лист, исходя из проблем и приоритетов компании. Подробно объясните свой выбор — это важная часть решения.
  • Оформите проверочный лист в виде Markdown-таблицы. В таком формате и вам, и ревьюеру будет легче отслеживать изменения в решении. При составлении листа можете опираться на шаблон, который мы дали в шестом уроке первой темы. Вот он в нужном формате. Заполните все поля проверочного листа, для которых достаточно данных.
Когда будете сдавать решение, загрузите проверочный лист в директорию Task2 в рамках пул-реквеста.

Задание 3. Внешние интеграции

PropDevelopment хочет расширить бизнес-функции для собственников и жильцов. Компания планирует добавить в систему новые сервисы «Умный дом». Эти сервисы готов предоставить партнёр.
Вы согласовали техническое задание с бизнесом и выбрали две услуги для внедрения:
  • Интеллектуальный домофон. Включает функции классического видеодомофона — открытие по звонку. Также есть возможность распознавать пользователей по биометрии (по лицу) и автоматически открывать дверь, если им разрешён доступ в дом.
  • Интеллектуальный шлагбаум. Включает функции классического управления шлагбаумом и автоматически открывает доступ, если распознаёт номера автомобилей, которым въезд разрешён.
Новые сервисы должны быть доступны через текущее мобильное приложение, которое используют собственники.

Что нужно сделать

  1. Подготовьте диаграмму контекста в модели С4. Она должна отражать контекст, в котором будут работать новые бизнес-функции.
  2. Доработайте диаграмму контейнеров PropDevelopment. Отразите на ней изменения, которые вы предлагаете сделать в ландшафте систем кампании в связи с внедрением новых бизнес-функций.
  3. Сформируйте список требований, которые должны удовлетворить внешние интеграции. Для этого:
    • опишите требования к безопасности,
    • выделите протоколы аутентификации и авторизации,
    • опишите, как будет организовано взаимодействие между системами предприятия и внешней платформой.
Когда выполните задание, загрузите в директорию Task3 диаграмму контекста, обновлённую диаграмму контейнеров и список требований.

Задание 4. Защита доступа к кластеру Kubernetes

В этом задании вы поработаете над решением технической задачи. Вам необходимо организовать ролевой доступ к Kubernetes для пользователей кластера.
Вот контекст и факты о ролевой модели:
  • Большинство бизнес-сервисов разворачивается в среде Kubernetes. Необходимо ограничить доступ к управлению кластером для различных групп пользователей.
  • Необходимо защитить кластер с помощью предоставления привилегированных действий (например, просмотра секретов) для определённых групп пользователей.
  • Кроме привилегированных групп пользователей, необходимо выделить ещё минимум две группы пользователей. У первой группы есть право только на просмотр ресурсов кластера. Вторая другая группа пользователей может настраивать кластер.
  • Необходимо разграничить доступ к ресурсам кластера, исходя из организационной структуры компании.

Что нужно сделать

  1. Поднимите пустой Minikube. В этот раз вы будете работать без тестового приложения. Изучать код не нужно, поэтому сфокусируйтесь на подготовке скриптов. Они должны будут отражать решения, которые получились у вас по итогу работы над первыми тремя заданиями. Для этого вам понадобится пустой Minikube.
  2. Определите все роли и их полномочия при работе с Kubernetes. Мы подготовили шаблон таблицы. Заполните её: укажите там роли, их полномочия и группы пользователей, которые им соответствуют.
  3. Подготовьте скрипты для создания пользователей. Рекомендуем создать не менее двух пользователей.
  4. Подготовьте скрипты, чтобы создать роли. Они должны соответствовать ролям из вашей таблицы.
  5. Подготовьте скрипты, чтобы связать пользователей с ролями.
Когда вы выполните задание, у вас должно получиться три файла: по одному скрипту на третий, четвёртый и пятый пункты задания. Когда будете сдавать работу, загрузите заполненную таблицу и скрипты в директорию Task4 в рамках пул-реквеста.

Задание 5. Управление трафиком внутри кластера Kubertnetes

В этом задании вам нужно разграничить трафик между сервисами, которые развёрнуты в кластере Kubernetes:
  • Вам необходимо добавить новый сервис. В терминах Kubernetes это под (pod). При этом нужно запретить другим подам с ним взаимодействовать.
  • Необходимо изолировать трафик к новому сервису от других подов.

Что нужно сделать

  1. В кластере, внутри одного namespace, вам необходимо развернуть четыре сервиса. В качестве самого сервиса используйте образ Nginx (вам не нужно создавать логику приложения в этом заданий).
  2. Назначьте метки для сервисов Метки выполняют функцию ролей для сервиса: 1. front-end 2. back-end-api 3. admin-front-end 4. admin-back-end-api

Для назначения меток используйте команду:

BASH

kubectl run front-end-app --image=nginx --labels role=front-end --expose --port 80
💡 Сервис можно назвать, добавив суффикс -app к имени сервиса. Так будет проще различать имя сервиса и его метку.
  1. Создайте сетевые политики
    Настройте сетевые политики так, чтобы разделить трафик между сервисами API (admin-back-end-api, back-end-api) и сервисами, которые используют их UI (front-end, admin-front-end).
    Таким образом, сетевые политики должны разрешить сетевой трафик в обе стороны между парой сервисов front-end и back-end-api, а также admin-front-end и admin-back-end-api.
    Сохраните сетевую политику в файл. Можете назвать его non-admin-api-allow.yaml. Затем примените сетевую политику, используя команду:

BASH

    kubectl apply -f non-admin-api-allow.yaml

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

BASH

    kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh
    / # wget -qO- --timeout=2 http://apiserver
Когда всё будет готово, загрузите файл с сетевыми политиками в директорию Task5.

Как сдать работу

В начале работы у вас должен быть Git-репозиторий «architecture-propdevelopment», в котором есть пять пустых директорий. Чтобы сдать своё решение на проверку, вам нужно сделать пул-реквест, который будет содержать все изменения.
В директории Task1 должен лежать mindmap, созданный в draw.io. Он должен отражать типы данных, которые использует компания, классы этих данных и соответствующие им риски.
В директории Task2 должен лежать проверочный лист для бизнес-систем компании.
В директории Task3 должны быть диаграмма контекста, обновлённая диаграмма контейнеров и список требований для внешних интеграций.
В Task4 — заполненная таблица со списком ролей и три файла скриптов.
В Task5 — файл с настройкой сетевых политик в кластере Kubernetes.
Перед отправкой решения проверьте, что вы включили в пул-реквест все нужные файлы. Если всё готово, отправьте ссылку на пул-реквест во вкладке «Ревью».
Не забудьте проверить, что репозиторий публичный. Если создадите приватный репозиторий, ревьюер не сможет прокомментировать ваше решение и вернёт его на доработку.
После того как отправите ссылку, не вносите изменения в проект. Дождитесь комментариев ревьюера.