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

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

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

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

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

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

• Много клиентских данных.
• Много систем, каждая из которых может разрабатываться и отгружаться по-своему.
• Много быстрой разработки ради time-to-market.
• Много подрядчиков.

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

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

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

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

1. Как переосмыслить практику хранения и применения личной информации в бизнес-процессах екома?
2. Как ограничить хранилища конфиденциальных данных?
3. Как найти баланс между количеством этих данных и требованиями к слабой связанности сервисов?

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

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

• Организационная безопасность.
• Безопасность инфраструктуры.
• Безопасность кода.

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

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

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

1. В большинстве случаев у подрядчика нет никакой реальной необходимости иметь доступ к персональным данным покупателей.
2. Ритейлер, владеющий этими данными, может предоставить доступ к ним только после подписания специального соглашения, где описаны условия работы с такими данными и ответственность всех участников процесса. Это серьезный документ.
3. Выдавать и контролировать эти доступы должен владелец данных — то есть, ритейлер.
4. Если ритейлер не выполняет какой-то из описанных выше принципов, подрядчик должен сам обеспечить их выполнение: помочь изолировать себя от чувствительной информации.

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

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

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

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

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

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

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

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

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

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

• Отключение возможности установки приложений;
• Ограничение удалённого подключения;
• Запрет использования внешних накопителей;
• Контроль доступа к интернет-ресурсам;
• Анализ зашифрованного трафика, передаваемых и принимаемых данных;
• Настройка антивируса и файрвола;
• Автоматическая блокировка компьютера при длительной неактивности и другое.

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

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

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

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

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

• Подписать с сотрудниками NDA и правила ИБ.
• Убрать внутренние сервисы за VPN.
• Обеспечить персональные доступы ко всем ресурсам.
• Оставить права доступа к уязвимым данным минимально необходимому числу сотрудников.
• Разграничить доступы к проектам.
• Ввести дополнительные меры для сотрудников, имеющих доступ к персональной информации.
• Сгенерировать тестовые данные вместо копий реальных баз.
• Регулярно проводить мероприятия по воспитанию культуры безопасности.

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

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

• Framework № PCI DSS 4.0 Requirement 6.5.3 — Предпроизводственная среда не может привносить риски и уязвимости в производственную среду;
• ГОСТ Р № 57580.1-2017 ЖЦ. 7 — Реализация запрета использования защищаемой информации в сегментах разработки и тестирования;
• СМЭ. 7 — Реализация запрета сетевого взаимодействия сегмента разработки и тестирования и иных внутренних вычислительных сетей финансовой организации по инициативе сегмента разработки и тестирования;
• NIST Cybersecurity Framework PR. DS-7 — Среда разработки и тестирования отделена от производственной среды;
• ГОСТ Р № ИСО/МЭК 27001-2021.

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

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

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

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

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

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

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

1. SSH-ключ на сервере.
2. Доступ через VPN.
3. Пароль/логин для конкретного сервиса или базы.

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

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

• SMS-подтверждение;
• USB-ключ безопасности;
• Электронная подпись;
• Биометический контроль доступа.

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

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

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

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

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

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

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

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

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

1. Вызывают сбои в работе системы и выводят ее из строя. Один из громких случаев: после обновления пакета node-ipc пользователи из России и Белоруссии столкнулись с полным удалением файлов со своих компьютеров;
2. Крадут данные, причем не всегда в виде записей БД. Целью могут быть, например, дампы памяти, в которых остается пароль администратора;
3. Открывают доступ к консольным командам, через которые можно загрузить вредоносное ПО или попытаться дальше взломать систему.

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

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

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

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

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

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

• Статические (например, SonarQube) — анализируют исходный код. Позволяют находить уязвимости на ранних этапах разработки (снижает затраты на исправление в будущем) и реагируют на большее число угроз. Из этого вытекает и главный недостаток: много ложно-позитивных срабатываний, каждое из которых отвлекает внимание разработчика.
• Динамические (например, PT BlackBox) — ищут уязвимости во время выполнения программы. Реже вызывает ложные срабатывания, не требует доступа к исходному коду и лучше выявляют ошибки, связанные с памятью и многопоточными процессами. Однако, у динамических анализаторов выше риск пропуска уязвимостей (например, временных бомб) , а для покрытия всего исходного кода требуется множество входных данных для воспроизведения условий реальной эксплуатации.

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

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

• Ограничить свободное добавление пакетов в репозиторий.
• Перед добавлением пакета в репозиторий проводить их проверку.
• Покрыть код проверками статичных и динамических анализаторов.
• Отслеживать уязвимости кода при проведении Code Review.

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

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

1. Подписать с сотрудниками NDA и правила ИБ.
2. Убрать внутренние сервисы за VPN.
3. Обеспечить персональные доступы ко всем ресурсам.
4. Оставить права доступа к уязвимым данным минимально необходимому числу сотрудников.
5. Разграничить доступы к проектам.
6. Ввести дополнительные меры для сотрудников, имеющих доступ к персональной информации.
7. Сгенерировать тестовые данные вместо копий реальных баз.
8. Регулярно проводить мероприятия по воспитанию культуры безопасности.
9. Разделить предпродуктивную и продуктивную среды.
10. Ограничить права доступа в соответствии с принципом минимальных привилегий.
11. Добавить несколько уровней аутентификации.
12. Делегировать отгрузку специалистам службы эксплуатации или девопс-инженерам.
13. Зашифровать уязвимые данные.
14. Ограничить подключение сервисов к интернет-ресурсам.
15. Ограничить свободное добавление пакетов в репозиторий.
16. Перед добавлением пакетов в репозиторий проводить их проверку.
17. Покрыть код проверками статичных и динамических анализаторов.
18. Отслеживать уязвимости кода при проведении Code Review.