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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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