{«id»:892059,»type»:»num»,»link»:»https:\/\/vc.ru\/trade\/892059-standarty-bezopasnosti-razrabotki-v-elektronnoy-kommercii»,»gtm»:»»,»prevCount»:null,»count»:0,»isAuthorized»:false}
{«id»:892059,»type»:1,»typeStr»:»content»,»showTitle»:false,»initialState»:{«isActive»:false},»gtm»:»»}
{«id»:892059,»gtm»:null}
1.8K
показов
95
открытий
Электронная коммерция и ритейл — активно развивающиеся области экономики. Однако скорость изменений в них не всегда сочетается с консервативной по своей сути информационной безопасностью.
Ритейлеры используют большое количество систем, внедрением и развитием которых занимаются разные подрядчики. Такой подход помогает растить бизнес, но увеличивает риски утечки клиентских данных, потому что не все команды находятся на одном уровне зрелости и уделяют достаточное внимание этим рискам.
Существенное число утечек случается не благодаря изощренным хакерским атакам, а из-за игнорирования базовых принципов информационной безопасности. Как пишет InfoWatch в 2022 году «почти в пять раз выросла доля утечек в группе «Ритейл&HoReCa», что, скорее всего, свидетельствует о низком уровне защиты информационных активов среди ряда розничных сетей, в общепите и службах доставки».
В этой статье мы рассмотрим основные меры, которые помогают существенно уменьшить вероятность воровства конфиденциальных данных.
Исходные положения
Для ритейла и екома справедливы следующие тезисы:
- Много клиентских данных.
- Много систем, каждая из которых может разрабатываться и отгружаться по-своему.
- Много быстрой разработки ради time-to-market.
- Много подрядчиков.
Другими словами положение дел можно описать как творческий беспорядок в бурно развивающейся отрасли. На этом фоне задача информационной безопасности заключается не только в защите конфиденциальных данных, но и в сохранении продуктивного потенциала команд, участвующих в развитии ритейл-компаний.
Главный принцип безопасности
Чтобы обеспечить безопасность не требуется внедрять все возможные технические и организационные меры — к процессу нужно подходить разумно, отталкиваясь от обстоятельств, ресурсов и возможных рисков.
Далеко не всем сервисам екома нужно хранить и обрабатывать данные клиентов, но иногда для ускорения разработки их бывает удобно поместить, например, в PIM в виде истории заказов, которая хоть и относится к товарам, но в то же время использует персональную информацию. Неконтролируемое распространение конфиденциальных данных по всей системе одновременно увеличивает угрозу от пропущенных дыр и способствует допуску к уязвимой информации большему числу лиц.
Вместо этого стоит выделить только те компоненты, где обработка чувствительной информации действительно необходима. Тогда при построении архитектуры возникнут нужные вопросы:
Необходимо минимизировать использование конфиденциальных данных и ограничить их обработку исключительно необходимыми сервисами.
Этот принцип безопасности имеет место на этапе проектирования. Но простые правила, внедренные тотально для всех ситуаций и сотрудников, снизят вероятность потерь при разработке и поддержке систем и сервисов весьма существенно.
Правила касаются трех аспектов:
- Организационная безопасность.
- Безопасность инфраструктуры.
- Безопасность кода.
Рассмотрим каждый из аспектов подробнее.
Организационная безопасность
В цитируемом выше отчете InfoWatch констатируется факт того, что ритейл пока не выработал практику бережного отношения к данным покупателей. Особенно в сравнении с финансовой информацией или, например, доступами в банковские системы. Нередки случаи, когда без предварительных условий компании открывают базы с персональными данными клиентов подрядчикам.
Ниже мы рассмотрим конкретные организационные меры, снижающие риски потери конфиденциальных данных, но сначала обозначим ряд принципов:
Договоры с сотрудниками
Первое что нужно сделать — уладить правовые отношения с сотрудниками в области безопасности. Для этого в компании составляют два документа:
Эти документы не только содержат правила информационной безопасности, которым должны следовать сотрудники, но и помогут снизить юридические риски на случай возможных утечек.
Трекеры и другие сервисы за VPN
В екоме многочисленные распределенные команды общаются и ведут проекты в разных средах: в мессенджерах, сервисах видеозвонков и трекерах задач. Первые два инструмента контролировать сложно и вряд ли целесообразно: это сервисы, которые используются сотрудниками и для личного общения. Стоит только обозначить общие принципы в документах и правилах, которые подписывают сотрудники. Например, никогда не передавать пароли в публичных чатах: для таких задач следует использовать менеджеры паролей.
А вот убрать за VPN системы планирования, ведения проектов, мониторинги и т. д. — обязательное мероприятие. Даже если политика безопасности не разрешает хранить в таких системах доступы к чувствительным данным, они могут попасть туда случайно.
Персональные доступы
Любые доступы должны быть персонализированы. Это относится ко всем ситуациям: оформление пропуска в офис, подключение к Wi-Fi, получение паролей к внутренним системам компаний и доступов к VPN и всему прочему.
1. Если случится утечка, расследование сможет определить, чей аккаунт был использован. Это также хорошая превентивная мера.
2. Если злоумышленник — один из сотрудников компании, легкость идентификации личности может сдержать его от слива данных.
3. Если сотрудник выбывает из проекта или увольняется, его легко изолировать от чувствительных данных. В отличии, например, от ситуаций, когда для доступов к базам используют общие логины/пароли.
В условиях текучки кадров, свойственной 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 факторам:
Как уже писалось выше, все доступы должны быть персональными.
Дополнительным фактором может быть стать из видов идентификации личности:
- SMS-подтверждение;
- USB-ключ безопасности;
- Электронная подпись;
- Биометический контроль доступа.
Отгрузки только через службу эксплуатации
Ограничение доступа к инфраструктуре — одна из конкретных рекомендаций по повышению безопасности. Все отгрузки и обновления приложений должны быть делегированы специалистам службы эксплуатации или девопс-инженерам.
Если в проекте не применяются методологии автоматизированной сборки и отгрузки, то стоит выделить такую роль в цепочке разработки, за которой будет закреплены обязанности по отгрузке результатов работы команды и выданы соответствующие доступы. Все остальные члены команды должны быть изолированы от этого процесса.
Шифрование данных
Автоматизированное развертывание сервисов подразумевает хранение доступов к другим компонентам системы в репозитории. В этом случае приходится уповать только на стойкость защиты хранилища. Но даже у крупнейших сервисов Github и Gitlab бывали утечки. Поэтому защищать конфиденциальную информацию нужно отдельно при помощи различных инструментов: переменных Gitlab, секретов K8S, key-value хранилища Hashicorp vault и других. Для шифрования данных в репозитории можно использовать Mozilla Sops (сервис хранения секретов) .
Также возможно ввести дополнительную меру: запрет хранения паролей в браузере. Хоть эту меру сложно контролировать, обычно пароли привязаны к почтовым аккаунтам — при их взломе атакующие могут синхронизировать данные для входа в другие, в том числе содержащие конфиденциальные данные, сервисы.
Купирование возможных последствий
Мероприятия по повышению безопасности могут идти не только в контексте предотвращения атак и утечек. Нужно также подумать о защите данных в случае успешной атаки.
Важно лишить злоумышленников возможности скопировать базу на сторонние площадки. Для этого следует ограничить доступ сервисов в интернет. Большинству из них необходима связь только с внутренними компонентами системы — и тогда их можно полностью отключить от Сети. В тех же случаях, когда интернет-соединение требуется для взаимодействия с данными, следует оставить только каналы взаимодействия с ограниченным числом действительно нужных сервисов.
Помимо риска утечки персональной информации незащищенные участки могут привести и к другой активности злоумышленников: от внедрения вредоносного ПО, например, майнеров до включения сервисов в сеть ботнета или использования уязвимой площадки для дальнейшего взлома.
Меры по обеспечению безопасности инфраструктуры
- Разделить предпродуктивную и продуктивную среды.
- Ограничить права доступа в соответствии с принципом минимальных привилегий.
- Добавить несколько уровней аутентификации.
- Делегировать отгрузку специалистам службы эксплуатации или девопс-инженерам.
- Зашифровать уязвимые данные.
- Ограничить подключение сервисов к интернет-ресурсам.
Безопасность кода
Наконец разберемся с мерами защиты непосредственно приложений. Основная угроза здесь — уязвимости в коде. Они могут быть и сравнительно безобидными — как уведомления о политических взглядах разработчиков, — и крайне серьезными. Три наиболее опасных типа:
Контроль используемых пакетов
Большинство разработчиков использует в работе открытые фреймворки и пакеты — убедиться в их безопасности гораздо сложнее, чем в коде, который написан внутри компании. Причем дыры могут присутствовать не в самом внешнем пакете, а в стороннем ПО, которые эти пакеты подгружают теневым образом. Такие цепочки могут быть довольно длинными, и отследить их самостоятельно едва ли возможно. Однако и с этим можно бороться.
Во-первых, следует ограничить установку внешних пакетов. Для начала будет достаточно организационных мер: прописать соответствующие правила, провести объяснительные беседы, назначить ответственных по контролю используемых библиотек.
Если контролировать защиту пакетов административными способами невозможно, имеет смысл обратить внимание на специальные безопасные репозитории — в них помещаются только одобренные ИБ-специалистами open source пакеты. Недавно в России появился первый доверенный репозиторий «РТК-феникс» от «Ростелекома».
Ещё один способ контролировать используемые пакеты — защищенные менеджеры репозиториев, такие как Sonatype Nexus Repository. Они обычно включают и возможность управления пакетами, и перечень безопасных библиотек, и встроенные инструменты для анализа.
Автоматический контроль кода
Снизить степень угрозы можно с помощью автоматического анализа кода — им занимаются специальные сканеры. Помимо поиска известных уязвимостей, такие анализаторы способны находить дыры, ошибочно или намеренно оставленные командой разработки приложения.
Сканеры бывают двух видов:
- Статические (например, SonarQube) — анализируют исходный код. Позволяют находить уязвимости на ранних этапах разработки (снижает затраты на исправление в будущем) и реагируют на большее число угроз. Из этого вытекает и главный недостаток: много ложно-позитивных срабатываний, каждое из которых отвлекает внимание разработчика.
- Динамические (например, PT BlackBox) — ищут уязвимости во время выполнения программы. Реже вызывает ложные срабатывания, не требует доступа к исходному коду и лучше выявляют ошибки, связанные с памятью и многопоточными процессами. Однако, у динамических анализаторов выше риск пропуска уязвимостей (например, временных бомб) , а для покрытия всего исходного кода требуется множество входных данных для воспроизведения условий реальной эксплуатации.
Важно, анализаторы не заменяют друг друга — макисмального покрытия можно достичь при совместном использовании и тех, и других.
Code Review
Проверка другим разработчиком — базовая мера повышения не только качества, но и безопасности кода. Случайно или специально оставленные дыры довольно легко выявляются на этапе Code Review, поэтому большую часть кода следует покрыть такими проверками.
Меры по обеспечению безопасности кода
- Ограничить свободное добавление пакетов в репозиторий.
- Перед добавлением пакета в репозиторий проводить их проверку.
- Покрыть код проверками статичных и динамических анализаторов.
- Отслеживать уязвимости кода при проведении Code Review.
Итоги
Чтобы внедрить меры, которые мы описали выше, требуется определенная работа и дисциплина для их поддержания. Однако, предлагаемые практики информационной безопасности не влияют на скорость разработки — важный критерий продуктивности команд в электронной коммерции и ритейле.
Пострадает удобство, а точнее станет невозможным беспечное отношение к вопросам ИБ, свойственное рядовым пользователям смартфонов, компьютеров и цифровых сервисов. В организации придется провести информационную кампанию и разъяснить всем сотрудникам, что предлагаемые меры продуманы, полезны и внедряются безусловно.
Краткий перечень мер и практик ИБ
