Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

DOU Labs: как в Infopulse создали Standards Compliance Manager — приложение для соблюдения стандартов

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

Привет, меня зовут Ирина Сигова. Я — Product Manager в Infopulse. Вместе со своей командой мы занимаемся развитием, разработкой и продажей продукта Infopulse Standards Compliance Manager. Это инструмент, который позволяет организациям оценивать свой текущий уровень безопасности и упрощает соблюдение требований безопасности и конфиденциальности. В этой статье расскажу, почему, зачем и как мы его создавали.

Проблема

Наша компания предоставляет IТ-услуги уже много лет. И мы делаем это системно и качественно. Но что такое «системно и качественно»? Нельзя просто прийти к клиенту и сказать: «Мы постараемся написать хороший код» или «Мы будем надёжно хранить и обрабатывать ваши данные». Это неубедительно. Гораздо лучше работают фразы вроде: «Мы гарантируем информационную безопасность на уровне ISO 27001». Более того — некоторые организации и разговаривать-то с вами не начнут, пока вы не скажете этого.

И вот перед нами возникает задача реально соответствовать этим (и некоторым другим) стандартам. У нас в компании работают люди, которые помнят ещё времена, когда стандартов было столь мало, а сами они были столь простыми, что для их реализации (и составления отчётности по ним) хватало, в общем, текстового редактора и почтового клиента. Хорошие были времена, но они давно прошли.

Современные стандарты — огромны. В том же стандарте безопасности ISO 27001 — около 1700 разнообразных требований, которые применяются ко всем аспектам деятельности компании. Всё это нужно реализовать, проверить, задокументировать — и только после этого можно надеяться пройти аудит и получить заветную отметку:

Очевидно, что простых инструментов, вроде текстового редактора и почтового клиента, для выполнения задач подобного масштаба уже недостаточно. Люди начинают «тонуть» в бумажной работе. Поддержание порядка в разрозненном наборе документов требует колоссальных усилий. Файлы хранятся в разных местах, имеют несколько версий. Что-то существует только на бумаге, что-то в электронном виде. Теряется контроль над ситуацией. Создать на основе всего этого правильный и актуальный отчёт по безопасности становится сверхзадачей.

Это была реальная ситуация, в которой мы когда-то оказались. И осознали, что с этим срочно нужно что-то делать. Нам нужен был правильный инструмент, который бы гарантировал правильный результат.

Идея

Наш отдел безопасности потратил некоторое время на обзор рынка уже существующих решений — кое-что действительно существовало, например решение Microsoft (Compliance Manager), либо продукт RSA (Archer). Мы читали описания продуктов, пробовали их демоверсии. Перебрали всё, что удалось найти. И ничего не подошло: где-то не было поддержки всех нужных нам стандартов, где-то — возможностей кастомизации, некоторые продукты морально устарели, другие не поддерживались.

Выбора не оставалось — инструмент нужно было создавать самим. Так родилась идея написания Infopulse Standards Compliance Manager. Мы хотели сделать инструмент, который позволил бы собрать и упорядочить все процессы и данные, связанные с поддержкой разнообразных стандартов в компании. Сделать невозможными неправильные действия, рассинхронизацию, потерю информации, неоптимальные пути решения проблем.

Пользователь должен быть уверен в том, что, если всё делать так, как того требует инструмент, — в итоге будет получен полностью пригодный для прохождения сертификации (например, ISO) набор документов.

Требования и выбор технологий

Мы решили делать web-приложение. Для Backend были выбраны Java 8 и Spring Boot 1.5. Классическое надёжное enterprise-решение. У нас в таких вещах большой опыт. Над клиентской частью думали, было сделано несколько proof-of-concept. Остановились на Angular, вторая версия которого тогда ещё находилась в Beta (но мы её всё равно взяли) и библиотеке компонентов для него под названием PrimeNG.

Одной из причин выбора Angular было желание команды работать над Backend и Frontend в одном, объектно-ориентированном стиле (многие разработчики пришли из Java), а Angular позволял писать на Typescript. Кроме того, мы сразу решили создавать Single-page application — а это то, в чём Angular ну очень хорош. Плюс к нему есть огромное количество дополнений и расширений — риск не найти чего-то нужного был минимален.

Что касается баз данных — нам была поставлена задача поддерживать как минимум Oracle, MySQL и MSSQL. Более того, мы должны были дать возможность использования бесплатных версий этих продуктов (Oracle XE и MSSQL Express). Если какие-то навороченные возможности БД не нужны — зачем за них платить?

Процесс разработки

В команде разработки у нас около 12 человек (включая продакт-оунера и скрам-мастера) При этом с нами постоянно работают 3 UX-специалиста, которые анализируют пользовательское поведение. Важно не только сделать, что пользователь «хочет», а что ему «нужно», что в действительности решит его боли и проблемы. Результаты таких инвестиций не заставляют себя долго ждать, мы часто получаем положительные отзывы о современности и интуитивности нашего продукта (особенно по сравнению с подобными продуктами на рынке).

Команда Infopulse Standards Compliance Manager

С точки зрения разработки и запуска продукта на рынок, его продаж, мы работаем как настоящий стартап, с очень гибкими подходами, постоянно экспериментируем и меняем процессы, все испытываем на личном опыте. Не так давно все же решили обратиться к теории и best practices, чтобы еще улучшить эффективность наших процессов. Работаем по scrum, в развитии продукта опираемся на основы Lean startup. Например, прежде чем инвестировать время в большую разработку чего-то нового, делаем прототип, тестируем на пользователях, получаем обратную связь и уже разрабатываем, то что пользователю нужно. Так мы, например, разработали наши дашборды, сделали прототип веб- и мобильной версии и показали на выставке в Германии (получили много полезной обратной связи).

Что касается инструментов, которые поддерживают нас в нашем гибком подходе, для планирования работы и также поддержки процесса разработки, используем Microsoft TFS. Это не совсем типично для scrum и Java-стека, но наша компания — партнёр Microsoft, опыт использования ее продуктов у нас большой. Так что если есть корпоративный (и хорошо настроенный) TFS-сервер, то почему бы его не использовать? Тем более он уже давно нормально поддерживает и Agile-разработку, и Git в качестве хранилища кода. Там у нас всё — спринты, задачи, баги. Настроен Continuous Integration — при слиянии каждого pull request запускается сборка на билд-агенте, прогоняются тесты. Кстати, что касается кода и пул-реквестов — есть определённые требования по их качеству. Например, каждый pull request должен быть одобрен минимум тремя разработчиками. Чем больше глаз увидит код — тем меньше шансов пропустить в нём ошибку.

На код пишем тесты (и юнит, и авто). Тестовые методы аннотируются, что позволяет Maven’у при сборке проекта автоматически выбрать и выполнить все тесты.

Использование базы данных

В проекте применяется такой инструмент, как Liquibase. Приложение хранит всю историю изменений структуры базы данных и само обновляет БД при необходимости. Это очень удобно — не нужно поддерживать никаких внешних скриптов, мы всегда точно знаем, что база данных целостна, а код соответствует её структуре.

Адаптация новых технологий

Продукт начинался и продолжает развиваться с намёткой на использование последних доступных технологий. Тот же регулярный переход на новые версии Angular позволяет нам, с одной стороны, гарантировать более высокую безопасность (многое в обновлениях этого продукта сфокусировано именно на этом), а с другой — поддерживать интерес разработчиков к продукту. Аналогично и с Backend — мы переходим на Java 11 и Spring boot 2.1. Ещё один момент — более современный стек технологий, который выделяет нас среди других продуктов. Когда мы участвуем на профильных выставках, первое, что нам говорят (ещё до знакомства с функционалом), — это насколько современно визуально выглядит продукт.

Deploy

Предполагается, что продукт будет разворачиваться на серверах заказчика. Поскольку Backend написан на Java, мы имеем возможность запускать его и на Linux, и на Windows-машинах. Также вскоре планируем начать его распространение через Azure Marketplace (сейчас идёт подготовка образа с последней версией продукта и его тестирование). Также мы можем сделать для заказчика образ виртуальной машины, Docker-контейнер или рассмотреть любые другие варианты установки, которые подойдут для его инфраструктуры.

Нагрузка и масштабируемость

Изначально у системы было одно виденье (поддержка лишь стандартов информационной безопасности), но сейчас наша материнская компания EVRY, которая имеет огромные массивы информации, ставит перед нами более высокие требования. Недавно мы сделали нагрузочное тестирование: результаты показали, что мы нормально «держим» нагрузку до 100 000 требований в одном стандарте. Поскольку на практике максимум, что нам встречалось, это стандарт на 1700 требований, можно сказать, что у нас есть очень большой запас по нагрузке на систему. Но нужно понимать, что цифра в 100 000 взята не «с потолка» — если взять такую компанию, как EVRY, и собрать абсолютно все требования абсолютно всех стандартов, используемых в различных департаментах, то где-то столько и получится. Конечно, никому не понадобится использовать их все одновременно, но мы потенциально готовы даже к такому сценарию.

По поводу количества пользователей — изначально предполагалось, что это решение только для Security Officers. Даже в больших организациях их не так много — единицы или максимум десятки. Но потом начали говорить о том, что мы хотим поддерживать и другие стандарты, не только в области безопасности. Сам продукт переименовался из Security Compliance Manager в Standards Compliance Manager. И получается, что теоретически очень многие специалисты компании могут иметь необходимость поработать в подобном инструменте в тех аспектах, которые касаются стандартов их профессиональной сферы.

Здесь, конечно, нагрузки будут уже совсем другими. Мы используем Tomcat в качестве сервера приложений, он нормально держит до 1000 клиентских соединений в базовой конфигурации. Этого уже хватит большинству клиентов. Если нужно больше, мы предлагаем горизонтальное масштабирование. Поскольку само приложение разрабатывалось как stateless, можно добавить сколько угодно серверов приложений (а при необходимости — и баз данных), и всё будет хорошо работать. При этом у нас очень скромные системные требования к железу — чего-то типа Intel Core i5 + 8 Гб ОЗУ уже достаточно для нормальной работы.

Работа с системой

Часть работы Security Officer состоит в оценке требований стандартов либо законодательств на соответствия. Пример того, как это осуществляется, в нашей системе выглядит так: у нас есть определённая структура стандарта — это требования, угрозы и меры по предотвращению угроз (Safeguards). Под каждым требованием может быть много угроз, под каждой угрозой — много мер по предотвращению. Для каждого узла на основе заполненных для него данных мы рассчитываем его статус, он отображается определенным цветом. Цвет самого нижнего «листа» дерева будет зелёным только тогда, когда по нему заполнена вся информация, и её достаточно, чтобы закрыть данный аспект полностью. Цвет родительского узла будет зелёным только тогда, когда зелёными являются все его дети. Таким образом, открыв дерево, мы сразу видим текущее положение дел: где всё уже хорошо, где ещё предстоит работа, а где у нас пока есть проблемы.

Отчёты

Одним из наиболее важных для конечного пользователя модулей является наша система отчётов — именно она создаёт те документы, которые будут использованы при аудите. Сейчас отчёты у нас встроенные, и их список фиксирован в соответствии с поддерживаемыми стандартами. Но мы идём к тому, чтобы дать пользователю возможность создавать и загружать новые шаблоны отчётов, которые точно будут необходимы для полноценной поддержки новых стандартов. Наши отчёты построены на фреймворке JasperReports (идеологически он очень похож на хорошо известный Crystal Reports). Он позволяет для каждого отчёта сделать XML-шаблон, описывающий его структуру. Возможны простые варианты, заполняющие отчёт готовыми данными, можно писать обработчики, передающие управление в код, и что-то рассчитывать на лету. В итоге генерируются отчёты в форматах PDF или XLS.

Добавление новых видов отчётов потребует дополнительной функциональности — нам будут необходимы не только функции создания и редактирования шаблона отчёта, но и возможности разделения прав доступа к нему между пользователями или их группами. Мы планируем сделать что-то вроде конструктора новых отчётов. Такой конструктор уже существует для JasperReports в виде десктопной утилиты, её уже сейчас можно использовать, но нам этот путь не нравится. Это требует от пользователя её установки, добавляет системе платформенную зависимость, и этот путь точно будет источником проблем для нас хотя бы потому, что требует от пользователя знания структуры нашей внутренней базы данных. А вот если мы дадим возможность создать отчёт прямо внутри нашего инструмента, то сможем предоставить пользователю набор примитивов, которым будем можно пользоваться без глубокого знания внутренней структуры нашего приложения и базы данных.

Добавление новых стандартов

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

Практическое применение

Что касается внутреннего использования продукта отделом безопасности Infopulse, то оно уже давно перестало быть «внутренним». С 2017 года, когда началась разработка первой версии продукта (который, кстати, назывался еще Security Compliance Manager), мы расширили область применения инструмента, и теперь пользователи SCM не ограничены только правилами и фреймворками безопасности, а могут применять наш инструмент в различных областях (безопасность, контроль качества процессов и т. п.) и индустрии (IT, фармацевтика, автомобилестроение и т. д.); могут оценить свою компанию, ее активы и процессы на соответствие (compliance) определенным стандартам и правилам. Расширив назначение области использования продукта, мы также сделали ребрендинг и изменили название продукта на Standards Compliance Manager. Слоганам продукта стали слова «Any standard, any process».

Сегодня мы используем SCM не только для себя, но и предоставляем услуги нашим клиентам. Кому-то нужно подготовиться к сертификации ISO, кому-то поддерживать GDPR, кому-то Secure Software Development Lifecycle (SDLC). Имея возможность создать в SCM много профилей организаций, мы можем предоставить все эти услуги. Либо клиент может купить наш продукт и заниматься этим уже лично, на своих серверах.

По отзывам Security Officers Infopulse, которые применяют SCM на практике каждый день, они наконец получили реальную систему для реальных людей и реальных задач. Инструмент соответствует их текущим потребностям и продолжает развиваться.

Дальнейшие планы

На данный момент в продукте запланирован достаточно большой процент стратегической разработки, новых модулей и функциональностей. Такая разработка значительно расширит возможности и добавит ценности нашему решению и конечному пользователю. В то же время постоянно появляются конкретные пользовательские запросы, которые мы берем в разработку.

Подробнее почитать о продукте и посмотреть реализацию можно на видео.

LinkedIn

2 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за вопрос! Использование ресурсов кубернетес для деплоймента системы пока не планируется — соответсвенно данных о размере docker image и результатах тестирования на масштабируемость пока нет. В качестве основной облачной площадки для деплоймента выбрана Azure.

Интересно делали ли деплой в кубернетес и тесты на масштабируемость в нем? Какой размер докер имаджа в итоге? Поддерживается ли алпайн как базовый имадж?

Подписаться на комментарии