Стандарты безопасности разработки в электронной коммерции

Электронная коммерция и ритейл — активно развивающиеся области экономики. Однако скорость изменений в них не всегда сочетается с консервативной по своей сути информационной безопасностью.

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

Существенное число утечек случается не благодаря изощренным хакерским атакам, а из-за игнорирования базовых принципов информационной безопасности. Как пишет InfoWatch в 2022 году «почти в пять раз выросла доля утечек в группе «Ритейл&HoReCa», что, скорее всего, свидетельствует о низком уровне защиты информационных активов среди ряда розничных сетей, в общепите и службах доставки».

В этой статье мы рассмотрим основные меры, которые помогают существенно уменьшить вероятность воровства конфиденциальных данных.

Для ритейла и екома справедливы следующие тезисы:

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

Чтобы обеспечить безопасность не требуется внедрять все возможные технические и организационные меры — к процессу нужно подходить разумно, отталкиваясь от обстоятельств, ресурсов и возможных рисков.

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

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

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

Правила касаются трех аспектов:

Рассмотрим каждый из аспектов подробнее.

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

Ниже мы рассмотрим конкретные организационные меры, снижающие риски потери конфиденциальных данных, но сначала обозначим ряд принципов:

Первое что нужно сделать — уладить правовые отношения с сотрудниками в области безопасности. Для этого в компании составляют два документа:

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

В екоме многочисленные распределенные команды общаются и ведут проекты в разных средах: в мессенджерах, сервисах видеозвонков и трекерах задач. Первые два инструмента контролировать сложно и вряд ли целесообразно: это сервисы, которые используются сотрудниками и для личного общения. Стоит только обозначить общие принципы в документах и правилах, которые подписывают сотрудники. Например, никогда не передавать пароли в публичных чатах: для таких задач следует использовать менеджеры паролей.

А вот убрать за VPN системы планирования, ведения проектов, мониторинги и т. д. — обязательное мероприятие. Даже если политика безопасности не разрешает хранить в таких системах доступы к чувствительным данным, они могут попасть туда случайно.

Любые доступы должны быть персонализированы. Это относится ко всем ситуациям: оформление пропуска в офис, подключение к Wi-Fi, получение паролей к внутренним системам компаний и доступов к VPN и всему прочему.

В условиях текучки кадров, свойственной IT-отрасли последние годы, персональные доступы ко всему — одна из главных мер.

В разработке одной системы могут участвовать несколько десятков человек из разных компаний: менеджеры, аналитики, дизайнеры, фронт- и бэк-разработчики и другие специалисты. Доступ к боевой базе системы, в которой хранятся данные реальных клиентов, требуется всего нескольким участникам команды, а все остальные должны быть изолированы от конфиденциальных данных.

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

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

Ни один из перечисленных способов не гарантирует 100%-ную защиту, поэтому всегда нужно думать о комплексе решений — чем больше степеней безопасности, тем выше вероятность предотвратить проблемы.

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

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

К сожалению, никакие меры не могут гарантировать абсолютной безопасности. А если слишком увлечься мероприятиями ИБ, можно навредить бизнесу, повлияв на time-to-market и возможность экспериментировать. К тому же, чрезмерное закручивание гаек влияет на атмосферу в команде и в результате может привести к оттоку ценных сотрудников: люди в IT чувствительны к таким вещам и на фоне большой востребованности легко меняют работу.

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

Выше мы упоминали, что тестовая среда — разработка и тестирование — как правило, менее защищена, чем среда продуктивная. Поэтому нужно отдельно позаботиться об изоляции предпродуктивного контура от боевого. Причем это должно быть реализовано и на логическом уровне, и в плане физического размещения.

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

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

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

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

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

Можно пойти дальше и создать DMZ (демилитаризованная зона) — область сети с выходом в интернет, не имеющей доступа к конфиденциальным БД или ограничивающей его. В DMZ связь с БД настраивается таким образом, чтобы при компрометации BFF важная информация оставалась защищена.

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

Прежде всего — это доступ к инфраструктуре разработки по 3 факторам:

Как уже писалось выше, все доступы должны быть персональными.

Дополнительным фактором может быть стать из видов идентификации личности:

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

Если в проекте не применяются методологии автоматизированной сборки и отгрузки, то стоит выделить такую роль в цепочке разработки, за которой будет закреплены обязанности по отгрузке результатов работы команды и выданы соответствующие доступы. Все остальные члены команды должны быть изолированы от этого процесса.

Автоматизированное развертывание сервисов подразумевает хранение доступов к другим компонентам системы в репозитории. В этом случае приходится уповать только на стойкость защиты хранилища. Но даже у крупнейших сервисов Github и Gitlab бывали утечки. Поэтому защищать конфиденциальную информацию нужно отдельно при помощи различных инструментов: переменных Gitlab, секретов K8S, key-value хранилища Hashicorp vault и других. Для шифрования данных в репозитории можно использовать Mozilla Sops (сервис хранения секретов) .

Также возможно ввести дополнительную меру: запрет хранения паролей в браузере. Хоть эту меру сложно контролировать, обычно пароли привязаны к почтовым аккаунтам — при их взломе атакующие могут синхронизировать данные для входа в другие, в том числе содержащие конфиденциальные данные, сервисы.

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

Важно лишить злоумышленников возможности скопировать базу на сторонние площадки. Для этого следует ограничить доступ сервисов в интернет. Большинству из них необходима связь только с внутренними компонентами системы — и тогда их можно полностью отключить от Сети. В тех же случаях, когда интернет-соединение требуется для взаимодействия с данными, следует оставить только каналы взаимодействия с ограниченным числом действительно нужных сервисов.

Помимо риска утечки персональной информации незащищенные участки могут привести и к другой активности злоумышленников: от внедрения вредоносного ПО, например, майнеров до включения сервисов в сеть ботнета или использования уязвимой площадки для дальнейшего взлома.

Наконец разберемся с мерами защиты непосредственно приложений. Основная угроза здесь — уязвимости в коде. Они могут быть и сравнительно безобидными — как уведомления о политических взглядах разработчиков, — и крайне серьезными. Три наиболее опасных типа:

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

Во-первых, следует ограничить установку внешних пакетов. Для начала будет достаточно организационных мер: прописать соответствующие правила, провести объяснительные беседы, назначить ответственных по контролю используемых библиотек.

Если контролировать защиту пакетов административными способами невозможно, имеет смысл обратить внимание на специальные безопасные репозитории — в них помещаются только одобренные ИБ-специалистами open source пакеты. Недавно в России появился первый доверенный репозиторий «РТК-феникс» от «Ростелекома».

Ещё один способ контролировать используемые пакеты — защищенные менеджеры репозиториев, такие как Sonatype Nexus Repository. Они обычно включают и возможность управления пакетами, и перечень безопасных библиотек, и встроенные инструменты для анализа.

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

Сканеры бывают двух видов:

Важно, анализаторы не заменяют друг друга — макисмального покрытия можно достичь при совместном использовании и тех, и других.

Проверка другим разработчиком — базовая мера повышения не только качества, но и безопасности кода. Случайно или специально оставленные дыры довольно легко выявляются на этапе Code Review, поэтому большую часть кода следует покрыть такими проверками.

Чтобы внедрить меры, которые мы описали выше, требуется определенная работа и дисциплина для их поддержания. Однако, предлагаемые практики информационной безопасности не влияют на скорость разработки — важный критерий продуктивности команд в электронной коммерции и ритейле.

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