Архитектура и хранение данных

• На платформе реализован механизм возможности входа пользователя под одной учётной записью только с одного устройства, то есть если пользователь заходит в систему со второго устройства, то на первом его сессия прерывается. Это сделано для исключения возможности жульничества при прохождении обучения и обеспечения безопасности аккаунта при необходимости заходить в систему с разных устройств.
• В Эквио реализован механизм журналирования — регистрация разного рода событий и действий. Журналирование реализовано для событий инфраструктуры (баз данных, служебных сервисов и т.д.), и здесь используется стек технологий ELK (ElasticSearch, LogStash, Kibana) — это механизм сбора централизованных журналов (все журналы собираются в одном месте и хранятся централизованно), и механизм просмотра этих журналов для инженеров DevOps и QA, чтобы понимать, что происходит с системой, если она ведёт себя нештатно. Вторая часть журналирования — это журналирование действий администраторов, существует возможность просмотра действий, которые приводят к созданию/изменению/удалению данных.

• Мониторинг — это технология, позволяющая в режиме реального времени собирать набор телеметрии от разных компонентов инфраструктуры и самой системы для понимания, что происходит с системой. Так проблемы выявляются проактивно, до того, когда они начнут влиять на работоспособность системы или, по крайней мере, до того, как о сбоях в работе начнут сообщать пользователи. Для этих целей мы используем технологии Prometheus и Grafana.
• Отказоустойчивость и масштабируемость системы. Отказоустойчивость означает, что в случае выхода из строя какого-то компонента системы у нас имеется возможность запуска новых копий, что обеспечивает высокий уровень доступности системы для пользователей. Для обеспечения отказоустойчивости используется система оркестрации Kubernetes. Масштабируемость — это способность системы при росте нагрузки на неё выдерживать эту нагрузку (обеспечивать комфортную работу пользователей) путём добавления дополнительных ресурсов в систему, не прерывая её работу, за это также отвечает система оркестрации Kubernetes.
• Мы регулярно проходим аудит системы требованиям OWASP (стандарт безопасности web-приложений). Как это выглядит: специальные программные инструменты сканируют нашу систему для того, чтобы выявить разного рода уязвимости, при выявлении уязвимостей мы их устраняем. По результатам работы проводится повторная проверка, которая подтверждает, что все уязвимости закрыты. Если клиент хочет провести инструментальный аудит нашей системы, чтобы убедиться в качестве нашей системы с точки зрения соответствия этим требованиям, то мы предоставляем все данные для этого, так как абсолютно уверены в нашем продукте.
• Следующий набор технологий, который мы используем для обеспечения стабильности работы системы — это резервное копирование и восстановление системы. В зависимости от того, каким образом развёрнут наш клиент, мы умеем по-разному проводить резервное копирование. В случае, если мы говорим о коммунальном облаке, мы реализуем резервное копирование в облако ВК, то есть в облако другого провайдера облачных услуг. Это делается для того, чтобы в случае возникновения проблем у Яндекса мы смогли в короткие сроки восстановиться с бэкапов и развернуться у другого провайдера. При этом восстановление производится только в случае катастрофы. Восстановиться из бэкапа по запросу конкретного заказчика, который случайно что-то удалил, невозможно, поскольку будут потеряны изменения у всех клиентов с момента создания резервной копии. В случае, если мы говорим о о выделенном облаке в Яндексе, мы реализуем резервное копирование в облако ВК, то есть в облако другого провайдера облачных услуг. Это делается для того, чтобы в случае возникновения проблем у Яндекса мы смогли в короткие сроки восстановиться с бэкапов и развернуться у другого провайдера. При этом восстановление возможно как в случае катастрофы, так и по запросу заказчика. В случае, когда мы разворачиваемся во внутренних контурах нашего заказчика, то, как правило, мы настраиваем резервное копирование в систему резервного копирования, которая предоставляется самим заказчиком. При этом восстановление возможно как в случае катастрофы, так и по запросу заказчика.

• Безопасная виртуальная инфраструктура. Для развёртывания коммунального облака или выделенных облаков мы используем технологию ЯндексCloud, которая соответствует высоким стандартам безопасности, а именно:
  — соответствие требованиям 152 ФЗ «О персональных данных»,
  — соответствие стандарту ISO 27001 (международный стандарт на соответствие требованиям безопасности). В наш договор с Яндексом включены пункты, гарантирующие со стороны Яндекса исполнение поставщиком облачных услуг требований 152 ФЗ.
  Кроме этого, облака от нашего провайдера расположены на территории РФ, что гарантирует их работу при самых жёстких санкциях и политических изменениях.
• Инфраструктурные компоненты нашей системы запускаются в docker-контейнерах. Эти контейнеры запускаются, в свою очередь, из образов, что исключает попадание в компоненты нашей системы постороннего и/или вредоносного ПО. То есть при каждом новом запуске контейнера, мы берём чистый образ этого контейнера, что позволяет нам обеспечить чистоту нашей инфраструктуры.
• Для запуска наших инфраструктурных сервисов не используются root-права, что означает, что даже если злоумышленникам удастся скомпрометировать какую-то часть нашей инфраструктуры, они не смогут захватить инфраструктуру в целом.
• С точки зрения надёжности технологий, которые мы используем (а абсолютно надёжных технологий не бывает), мы в нашей инфраструктуре используем только компоненты с открытым исходным кодом, которые являются production ready.

• Мы реализуем безопасный процесс разработки нашего ПО, который называется CI/CD (Continuous Integration / Continuous Delivery), в рамках которого реализуется длинный flow разработки, который предполагает как саму разработку и тестирование, так и развёртывание и обновление нашего кода. Правка разработчиками в production невозможна, то есть весь код, который ими пишется и дорабатывается, проходит проверку через QA на отсутствие в нём багов или минимизацию их количества, а развёртыванием ПО и инфраструктуры занимается отдельная команда DevOps. На каждом из этапов этого процесса все сотрудники используют персональные учётные записи, полномочия которых ограничены только тем, что необходимо сотруднику для выполнения им должностных обязанностей.
• В нашей системе не хранятся пароли пользователей в открытом виде, то есть нет возможности зайти в базу данных и посмотреть, какой пароль у того или иного пользователя. Для этого мы используем хэширование паролей и их соление. Это технология, которая позволяет обеспечить необратимый процесс преобразования пароля при его сохранении в базе данных.
• У нашей системы есть интеграционное API, которое соответствует стандарту OpenAPI. Оно является с одной стороны открытым (мы публикуем документацию по нашему интеграционному API для того, чтобы клиенты могли самостоятельно разрабатывать механизмы интеграции), с другой стороны — безопасным, потому что для доступа к нашему интеграционному API клиентам выдаются специальные токены, которые обеспечивают защиту доступа. Таким образом, злоумышленник использовать наше интеграционное API не сможет, потому что он не владеет соответствующим токеном. Токен передается только уполномоченным сотрудникам Заказчика.
• Мы зарегистрированы в Роскомнадзоре как оператор персональных данных, нами разработан и реализуется ряд организационных технических мер по защите персональных данных в соответствии с требованиями подзаконных актов к 152 ФЗ, а также нами разработан необходимый комплект документов, которые требуются в соответствии с нормативными документами ФСТЭК (Федеральная служба по техническому и экспортному контролю) для организаций, которые обрабатывают персональные данные. При передаче данных между нашей инфраструктурой и клиентскими устройствами мы используем защищённые протоколы (в частности, https). Для доступа наших инженеров к инфраструктуре также используются защищённые протоколы ssh. В том случае, если наша система и кадровая система заказчика находятся в разных местах, например, наша система развёрнута в коммунальном или выделенном облаке, а система заказчика развёрнута в его внутреннем контуре, если заказчик требует, мы можем построить VPN-туннель между нашей инфраструктурой и инфраструктурой заказчика. При этом туннель при необходимости будет построен с использованием сертифицированного ФСБ продукта для построения таких туннелей, что соответствует требованиям 152 ФЗ. Также нами разработан и реализуется ряд требуемых регулятором документов, которые регламентируют наши действия по обработке персональных данных и их защите.

Автор:

Валерий Полубояров — руководитель отдела бизнес-аналитики и внедрения в компании Эквио