FAQ: Безопасность программного обеспечения

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

Предназначено для: ИТ-отдел
Последнее изменение: 21 сентября 2023

Принципы безопасности

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

Безопаснее по дизайну

Мы считаем, что дизайн является одним из самых недооценённых аспектов безопасности программного обеспечения. Здесь дизайн охватывает фундаментальные решения, принятые при разработке ПО. Решения, принимаемые компанией на этапе проектирования, имеют огромное значение для безопасности, особенно что касается площади атаки. Благодаря разумному дизайну, Lokad устранил целые классы проблем с безопасностью. Например, Lokad не использует базу данных SQL, а применяет простое blob-хранилище в качестве строго пассивного слоя. Этот выбор сам по себе предотвращает целые группы проблем с безопасностью, такие как атаки SQL-инъекций, поскольку SQL-базы для атаки просто не существует. Аналогично, все наши уровни хранения данных являются только добавляемыми (append-only). Это похоже на системы контроля версий, где изменения добавляются в конец существующих данных, а не перезаписывают их полностью. Все изменения отслеживаются и могут быть отменены. Этот шаг существенно осложняет удаление любых данных (кем бы то ни было, включая злоумышленников), а также попытки подделки логов Lokad.

Большинство поставщиков корпоративного программного обеспечения не признают, что ключевые решения в области проектирования являются основой их программных продуктов. В результате их проблемы с безопасностью бесконечны. Например, если настраиваемость — почти всегда требуемое условие для корпоративного ПО — обеспечивается посредством общего программного языка (такого как Python или JavaScript), неизбежно возникают проблемы безопасности. Это связано с тем, что практически невозможно полностью обезопасить общий программный язык. В отличие от этого, Lokad сознательно решил направить всю настраиваемость через специализированный DSL (предметно-специфический язык программирования) под названием Envision. Envision намного безопаснее, поскольку изначально не обладает возможностью прямого взаимодействия с операционной системой и её подсистемами, такими как файловая система.

Безопаснее благодаря культуре

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

Во-первых, Lokad стремится максимально соотнести свои маркетинговые сообщения с реальностью бизнеса. Мы делаем это, независимо от того, вызывает ли это у нас симпатию или критику. Это резко контрастирует с поведением многих поставщиков корпоративного ПО, делающих необоснованные (а часто и фантастические) заявления ². Когда происходит последнее, сообразительные сотрудники — те, кто способен заметить несоответствие между реальностью бизнеса и тем, что транслируется внешнему миру — перестают заботиться. Такое равнодушие порождает самодовольство, за которым следуют проблемы с безопасностью. Часто такие сотрудники увольняются, оставляя в компании «доверчивых» — тех, кто не замечает несоответствия. Доверчивость, как и безразличие, не является желательной чертой с точки зрения безопасности.

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

Безопаснее благодаря обучению

Мы активно обучаем весь наш персонал, чтобы они лучше понимали киберугрозы и умели их нейтрализовать. В отличие от дизайна и корпоративной культуры, обучение безопасности в основном осуществляется сверху вниз. Хотя подход снизу вверх имеет свои преимущества, этот тип обучения по своей природе недостаточно эффективен против большинства компьютерных угроз. Проще говоря, даже если людей обучают не делать чего-либо, Lokad не может предполагать, что кто-либо никогда не совершит эту ошибку ⁴. Поэтому мы придерживаемся более строгого подхода. В рамках обучения мы не рекомендуем использовать USB-флешки и другие USB-устройства, которые могут представлять угрозу для оборудования. Мы обеспечиваем использование двухфакторной аутентификации, когда это возможно. Обучаем сотрудников работать с минимально необходимыми привилегиями на их рабочих станциях. Мы также следим за тем, чтобы каждый понимал принципы социальной инженерии, которая может обмануть даже самых умных людей.

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

Часто задаваемые вопросы (FAQ)

1. Практики

1.1 Есть ли у вас гарантии безопасности?

Да. Гарантии безопасности — это обобщающий термин для ряда практик, таких как укрепление безопасности, тестирование безопасности и управление уязвимостями. В Lokad укрепление безопасности в первую очередь осуществляется через дизайн. Благодаря специфическим решениям в области проектирования мы устраняем целые классы уязвимостей, что, в свою очередь, исключает необходимость в самом укреплении. Например, Lokad не использует “программный” уровень хранения данных — такой как реляционная база данных — а применяет простой ключ-значение хранилище. Это исключает все векторы SQL-инъекций. Более того, тестирование безопасности проводится с помощью различных методов: автоматизированных и ручных, таких как сторонние тесты на проникновение. Для управления уязвимостями у нас есть программа bug bounty, а также полностью автоматизированный процесс управления релизами, обеспечивающий оперативное развертывание исправлений.

1.2 Соответствуют ли вы стандартам ISO 27001 (ISMS) и/или SOC 2?

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

В кругах разработчиков ПО безопасность обычно достигается путём снижения активности, а не добавления новых мер; за счёт использования усилий инженеров, специализирующихся на безопасности, а не создания дополнительных команд неспециалистов. К примеру, подумайте о некоторых самых серьёзных киберкатастрофах, таких как Heartbleed или Log4Shell. Эти бедствия, вероятно, можно было бы предотвратить, если бы тысячи “сертифицированных” компаний-разработчиков ПО выбрали приоритетную проверку стороннего кода — часто являющегося источником проблем — вместо того, чтобы стремиться к произвольным коммерческим сертификатам.

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

1.3 Соблюдаете ли вы практики OWASP?

Да. OWASP посредством своих руководств предоставляет обширный чек-лист уязвимостей, часто встречающихся в программном обеспечении. Это обширная, качественная компиляция, которую инженеры Lokad используют для защиты нашего ПО от любых выявленных у OWASP проблем. Однако благодаря сделанным выбором в дизайне Lokad во многом устраняет целые классы распространённых уязвимостей, на которые указывает OWASP. Например:

Управление паролями: Благодаря делегированию аутентификации через функцию единого входа (SSO, что рекомендовано Lokad), необходимости “управлять” паролями больше нет, что делает весь чек-лист, связанный с паролями, бессмысленным.

Ведение логов: Принятая в Lokad схема с использованием event sourcing автоматически регистрирует всё. Если действие не зарегистрировано, то с точки зрения системы оно никогда не происходило. Это аннулирует большую часть чек-листа по ведению логов.

Безопасность базы данных: Слой хранения данных в Lokad не включает реляционную базу данных, а состоит только из двух не программных компонентов: event source и key-value store. Этот выбор в дизайне полностью отменяет необходимость чек-листа по базе данных.

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

1.4 Соответствуете ли вы требованиям GDPR?

Да. Однако оптимизация цепочки поставок, предлагаемая Lokad, не требует персональных данных. Мы считаем, что персональные данные — это скорее ответственность, чем актив. Поэтому мы настоятельно рекомендуем нашим клиентам не передавать нам персональные данные. Это рекомендации, как правило, являются частью наших договорных соглашений. Отсутствие у нас персональных данных, а значит и их обработки, существенно устраняет проблемы и протоколы, связанные с их защитой, такие как GDPR или аналогичные регламенты.

1.5 Соответствуют ли все сторонние сервисы/решения (включающие доступ к персональным данным, позволяющим идентифицировать личность (PII)) в решении Lokad требованиям ответственного за защиту данных (DPO)?

Да. Однако, как указано в Пунктах 1.4, оптимизация цепочки поставок, предлагаемая Lokad, не требует персональных данных. Поэтому мы настоятельно рекомендуем нашим клиентам не передавать нам персональные данные.

Следует отметить, что в решении Lokad список сторонних организаций, имеющих доступ к PII, очень короткий. По состоянию на январь 2023 года этот список ограничен Microsoft Azure.

1.6 Соблюдаете ли вы лучшие практики безопасности?

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

1.7 Проводите ли вы регулярно тесты на проникновение?

Да. У нас проводятся как плановые, так и внеплановые тесты на проникновение. Плановые обычно финансируются нашими крупными клиентами, которые согласно подписанным с ними контрактам могут нанимать специализированные компании для проведения тестов на проникновение ключевых поставщиков программного обеспечения, включая Lokad. Обычно существует определённая степень координации между инженерной командой Lokad и этими специалистами по безопасности. Внеплановые тесты обычно проводятся в рамках нашей открытой публичной программы bug bounty, где внештатные специалисты по безопасности могут попытаться выявить уязвимость в нашей системе, способную привести к потенциальному эксплойту.

1.8 Проводите ли вы регулярно внешние аудиты?

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

1.9 Есть ли у вас План обеспечения непрерывности бизнеса?

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

1.10 Есть ли у вас план кризисной коммуникации?

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

1.11 Как вы обеспечиваете безопасность ИТ-систем клиента?

Мы настоятельно рекомендуем, чтобы Lokad не имела доступа к ИТ-системам наших клиентов; ИТ-система клиента должна только отправлять и получать данные от Lokad. Такой подход предназначен для снижения риска того, что инцидент безопасности в Lokad сможет распространиться на ИТ-систему клиента. Кроме того, мы также настоятельно рекомендуем использовать процесс единого входа (SSO), поскольку он устраняет гипотетический сценарий, при котором пароль, используемый для доступа к Lokad, каким-либо образом перехватывается и затем используется для компрометации одной из ИТ-систем клиента.

1.12 Как вы обеспечиваете безопасность своей сети?

Наш дизайн основывается на архитектуре Zero Trust, то есть допускаются только те люди, которые имеют право доступа к данным в данный момент. Простое нахождение в нашей сети не предоставляет автоматического статуса или привилегий (этот пункт подробнее раскрывается в Authentication 2.1). Таким образом, несмотря на наше внимание к сетевой безопасности, мы на первоначальном этапе стремимся максимально сократить поверхность атаки, связанную с нашими сетями.

Lokad использует две заметные сети. Первая — это Microsoft Azure, которая используется для размещения нашего решения. Безопасность сети Microsoft Azure полностью возлагается на Microsoft. Мы не используем «расширенные» сетевые возможности — такие, как те, что предлагает Microsoft Azure — помимо базовых балансировщиков нагрузки.

Вторая — это локальная сеть нашего головного офиса в Париже. Безопасностью локальной сети управляет внутренняя инженерная команда Lokad. Наша локальная сеть не размещает никаких компонентов или систем, участвующих в производственной среде.

1.13 Гарантируете ли вы, что все компоненты (включая сторонние) и инструменты (включая с открытым исходным кодом), интегрированные в решение, являются юридически допустимыми для разработки и эксплуатации?

Да. По сравнению с большинством поставщиков корпоративного программного обеспечения, у Lokad очень мало зависимостей. Все наши основные зависимости — это надёжные и широко используемые проекты с открытым исходным кодом (например: .NET от Microsoft, React от Facebook). Это делает наш внутренний аудит по этому вопросу довольно простым.

1.14 Как вы управляете значительными изменениями в организации и процессах с точки зрения безопасности?

Так как Lokad с самого начала приняла разумные решения и практики в области безопасности, маловероятно, что изменение любого масштаба (будь то незначительное или крупное) окажет влияние на безопасность (даже гипотетически). За всю историю Lokad было лишь 3 события, которые можно считать действительно значимыми с точки зрения безопасности: миграция на Microsoft Azure в 2010 году; внедрение делегированной аутентификации в 2012 году (как для клиентов, так и для сотрудников); и, внутри Lokad, миграция с Google Authentication на Microsoft Azure AD в 2022 году.

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

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

1.15 Как вы управляете завершением контракта?

Наши соглашения детально описывают процесс расторжения контракта, согласованный с клиентом. Процесс расторжения заканчивается окончательным удалением данных клиента. Поскольку этот процесс сам по себе представляет риск с точки зрения безопасности, данный вопрос обсуждается с каждым клиентом и может незначительно варьироваться в зависимости от конкретного случая. С точки зрения безопасности, злоумышленник с недобрыми намерениями может попытаться выдать себя за клиента, чтобы инициировать досрочное расторжение контракта (и нарушить работу клиента). Чтобы предотвратить это, Lokad и клиент совместно стремятся принять процесс — закреплённый контрактом — который не является тривиально уязвимым для атак социальной инженерии. Этот процесс обычно включает письменные подтверждения и обязательную задержку.

1.16 Какова стратегия лицензирования Lokad, модель затрат и модель ежегодного обслуживания?

Обычно Lokad взимает единую ежемесячную плату, связанную с эксплуатационными затратами платформы, плюс отдельную ежемесячную плату за услуги, предоставляемые специалистами по цепочке поставок, назначенными клиенту (то есть инженерами, предоставляемыми Lokad). Детали прописываются и оговариваются в договоре о предоставлении услуг между клиентом и Lokad. Эти два платежа представляют собой пакет «все включено» от Lokad. Дополнительных затрат на обслуживание, лицензионных платежей, платы за сторонних интеграторов или консультантов не предусмотрено. Пакет имеет ограничения по объему и масштабам, которые согласовываются совместно в рамках договорного соглашения.

1.17 Можете ли вы предоставить условия и положения Lokad для лицензий, услуг, поддержки, обслуживания и обучения?

Да, по запросу клиента мы можем предоставить шаблон контракта, представляющий собой «базовое» соглашение. Однако ситуации значительно различаются в зависимости от масштабов инициативы в области цепочки поставок, применимых стран и объема ожидаемых услуг от Lokad. Поэтому, если это возможно, мы предпочитаем провести предварительное обсуждение с потенциальным клиентом, чтобы уточнить детали рассматриваемой инициативы в области цепочки поставок. Это помогает нам разработать наиболее подходящую договорную базу для конкретной ситуации.

1.18 Предоставляете ли вы обучение (на месте/удалённое обучение)?

Да, Lokad предоставляет как очное, так и удалённое обучение. Детали проведения этих сессий оговариваются в рамках договорного соглашения. Кроме того, Lokad располагает обширной публичной технической документацией и подробной серией публичных лекций по цепочке поставок. Эти лекции охватывают технологии Lokad и его взгляд на цепочку поставок.

1.19 Соответствует ли система Lokad применимым юридическим/местным стандартам (например, ISO)?

Да, Lokad работает в соответствии с применимыми стандартами. Однако Lokad предоставляет предиктивную оптимизацию цепочки поставок, и, как таковая, не осуществляет прямого контроля над операциями. Наше влияние в основном опосредованное, обычно посредством оптимизации распределения ресурсов. Таким образом, стандарты ISO здесь не актуальны (то есть не применимы к Lokad).

1.20 Есть ли защита от вредоносного ПО на сетевом уровне, например, на межсетевых экранах, прокси-устройствах и/или в виде отдельных решений в сети?

См. Практика 1.12

1.21 Включает ли процесс разработки программного обеспечения встроенную оценку угроз?

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

1.22 Проводится ли отработка процесса управления инцидентами не реже одного раза в год?

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

1.23 Проводится ли ревизия картирования рисков и угроз не реже одного раза в год?

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

1.24 Проводится ли оценка рисков также для вспомогательных функций, которые могут повлиять на доступность, качество и/или безопасность решения?

Да. Однако платформа Lokad по сути является монолитом и не зависит от каких-либо «вспомогательных функций», за исключением нескольких основных компонентов, таких как Blob Storage и виртуальные машины Linux, предоставляемые Microsoft Azure.

1.25 Создаются ли выделенные системные учетные записи — с лишь необходимыми правами доступа — для запуска системных процессов?

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

Хотя Lokad не использует SQL-базу данных, платформа применяет ролевую систему для определения прав доступа к запланированным и запускаемым процессам. Эти процессы классифицируются как «пользовательские», а не «системные».

1.26 Существует ли формализованный план управления рисками, одобренный руководством, который определяет требования программы корпоративного управления рисками?

Да, у нас существует формализованный план управления рисками, который был утвержден высшим руководством.

Этот план содержит требования и рекомендации для нашей программы корпоративного управления рисками (ERM). Он предназначен для выявления, оценки, управления и мониторинга рисков на уровне предприятия в структурированной и последовательной форме.

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

1.27 Существует ли программа физической безопасности, одобренная руководством, доведенная до сведения участников и с назначенным ответственным за её поддержку и проверку?

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

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

1.28 Проводятся ли оценки физических и экологических рисков до выбора места расположения объекта, где располагаются системы?

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

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

1.29 Существует ли документированная программа внутреннего соответствия и этики?

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

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

Таким образом, Lokad сосредоточен на том, чтобы сотрудники имели возможность искренне заботиться о наших клиентах. «Делаем ли мы правильные вещи?» — один из наших девизов. По нашему мнению, соблюдение норм и этика являются побочным результатом адекватной корпоративной культуры, а не результатом какой-либо отдельной программы.

1.30 Существует ли внутренний отдел аудита, управления рисками или комплаенса, или аналогичная функция управленческого контроля, ответственная за отслеживание решения нерешенных нормативных или комплаенс вопросов?

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

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

1.31 Существует ли одобренная руководством политика или программа для беспроводных сетей, доведенная до сведения соответствующих участников и с назначенным ответственным за её поддержку и пересмотр?

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

Однако важно отметить, что наше основное подключение осуществляется через Ethernet, который имеет приоритет благодаря своей высокой производительности и повышенной безопасности. Беспроводные сети Wi-Fi в основном используются для проведения встреч и обеспечения гибкости в определенных ситуациях.

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

2. Аутентификация

2.1 Обязываете ли вы использовать аутентификацию для всех доступов?

Да. Для доступа к данным клиентов и/или любой существенной функциональности решения требуется предварительная аутентификация. Однако, по необходимости, некоторые точки контакта не требуют аутентификации. Например, доступ к странице входа не требует предварительной аутентификации (так как сама аутентификация и является целью этой страницы входа).

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

2.2 Требуете ли вы, чтобы все удаленные подключения были защищены? Обязываете ли вы использовать HTTPS для веб-соединений?

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

2.3 Предоставляете ли вы SSO (единый вход в систему)? Поддерживаете ли вы Active Directory (AD)?

Да. Мы предоставляем SSO (единый вход в систему) через протокол SAML. Active Directory поддерживает SAML и может использоваться для доступа к Lokad.

2.4 Поддерживаете ли вы двухфакторную аутентификацию, например, EZToken, Google Authenticator или Microsoft Authenticator?

Да. Двухфакторная аутентификация осуществляется посредством делегированной аутентификации через SAML. При использовании SAML Lokad не управляет ни первым, ни вторым фактором аутентификации, так как этот процесс делегируется.

2.5 Поддерживаете ли вы протокол аутентификации OAuth2?

По умолчанию Lokad поддерживает протокол аутентификации SAML. Этот протокол поддерживается основными федеративными системами идентификации, такими как Microsoft Office 365 или Google Workspace. Проблема поддержки OAuth2 заключается в том, что OAuth2 на самом деле не является протоколом аутентификации, а представляет собой набор очень обширных рекомендаций по созданию протоколов аутентификации, которые могут отличаться десятками способов.

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

2.6 Поддерживаете ли вы интеграцию LDAP?

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

2.7 Обязываете ли вы использовать двухфакторную аутентификацию?

Для сотрудников Lokad — да. Для сотрудников клиента мы настоятельно рекомендуем это, но в конечном итоге не можем применить обязательное правило (так как аутентификация обычно делегируется через SSO). Этот вопрос находится в ведении IT-отдела нашего клиента, а не нашего.

2.8 Можете ли вы обеспечить минимальную сложность пароля?

Да, но в ограниченной степени. Что касается безопасности программного обеспечения, требование минимальной сложности пароля теперь в значительной мере признается плохой практикой. Конечные пользователи плохо (и предсказуемо) реагируют на чрезмерно строгие требования к сложности пароля, что негативно сказывается на общем уровне безопасности. Кроме того, мы рассматриваем такие требования как «лишний функционал», который увеличивает сложность критически важного для безопасности программного обеспечения (управление паролями), тем самым подвергая его (и общее решение) неоправданным рискам. См. https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Мы настоятельно рекомендуем использовать SSO вместо традиционных паролей/стратегий. При использовании SSO нет необходимости вводить пароль, предназначенный исключительно для Lokad.

2.9 Можете ли вы обеспечить регулярную смену паролей?

Мы могли бы это сделать, но не делаем. Подобно минимальной сложности паролей (см. Аутентификация 2.8), регулярная смена паролей теперь в значительной мере признается плохой практикой в области безопасности программного обеспечения. Конечные пользователи плохо (и предсказуемо) реагируют на запрограммированную смену паролей. Безопасность может даже ухудшиться, поскольку сотрудники зачастую вносят лишь незначительные изменения в пароли (чтобы снизить когнитивную нагрузку, связанную с частой сменой паролей). Как и в случае с минимальной сложностью паролей, мы рассматриваем смену паролей как «лишний функционал», увеличивающий сложность критически важного для безопасности программного обеспечения (управление паролями), тем самым подвергая его (и общее решение) неоправданным рискам. См. https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Применяете ли вы хеширование с солью для паролей?

Да. Мы используем scrypt в качестве функции хеширования паролей. Как общее правило, мы настоятельно рекомендуем использовать SSO вместо традиционных паролей/стратегий. При использовании SSO нет необходимости вводить пароль, предназначенный исключительно для Lokad.

2.11 Предусматривает ли решение Lokad использование CAPTCHA после определенного числа неудачных попыток аутентификации?

Да, хотя это осуществляется через делегирование аутентификации (через SSO). Хотя CAPTCHA является ценным инструментом для снижения некоторых векторов атак, она относится к программным компонентам, использование которых лучше оставить вне рамок решения для оптимизации цепочки поставок, такого как Lokad. Более того, дополнительная ценность CAPTCHA в контексте корпоративного ПО менее очевидна, чем в случае B2C-софта, особенно бесплатного.

2.12 Существует ли общая политика безопасности в отношении паролей? Существует ли процесс ее обеспечения?

Да. Наша общая политика безопасности паролей — «без паролей». Мы настоятельно рекомендуем SSO, что устраняет необходимость введения паролей, предназначенных исключительно для Lokad.

2.13 Централизуете ли вы управление пользователями?

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

2.14 Разрешаете ли вы использовать общие/генерические учетные записи?

Нет. Lokad обеспечивает соотношение «один к одному» между сотрудниками и пользователями (согласно платформе Lokad). Мы настоятельно не рекомендуем использование общих учетных записей. Фактически, одной из причин, по которой мы не взимаем плату за каждого пользователя, является избежание стимулирования клиентов к обмену учетными записями среди их сотрудников. Однако существуют случаи, где допустимо наличие учетной записи без соответствующего сотрудника. Как правило, это происходит для клиентской службы «robot upload», отвечающей за передачу данных в Lokad. В рамках нашей системы RBAC (контроль доступа на основе ролей) у нас существует специализированная роль (называемая «uploader»), предоставляющая минимальные права для этого единственного случая использования.

2.15 Предоставляете ли вы защищенные VPN-соединения?

Нет. Подключения конечных пользователей осуществляются через зашифрованные каналы (обычно TLS).

2.16 Разрешаете ли вы пользователям входить в систему с нескольких устройств?

Да, в определенных пределах. В общем, верхний предел составляет 6 устройств на пользователя (мы не взимаем плату за подключение с нескольких устройств). Каждая сессия ограничена одним IP-адресом. Однако Lokad оставляет за собой право изменить этот лимит для противодействия потенциальным угрозам и/или злоупотреблениям.

2.17 Обладает ли решение возможностью принудительно заблокировать и/или выйти из системы пользователя (если он считается вредоносным)?

Да. Эта функция требует прав доступа «Owner» в аккаунте Lokad.

2.18 Осуществляет ли система автоматический выход из системы для неактивного пользователя после определенного периода бездействия?

Да, хотя «бездействие» не является определяющим фактором. Lokad автоматически выводит пользователей из системы после истечения заданного времени. Пользователи не могут отсрочить выход, оставаясь «активными»; по истечении указанного времени им необходимо пройти повторную аутентификацию.

2.19 Запрещено ли использование общих учетных записей и/или данных доступа, и контролируется ли соблюдение этих политик?

Да. См. Аутентификация 2.14.

2.20 Передаются ли идентификаторы пользователей и пароли средствами, отличными друг от друга (например, по электронной почте и телефону)?

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

Внешне, для сотрудников клиентов, подключающихся к нашим системам, мы настоятельно рекомендуем использовать Single Sign-On (SSO) и федеративные системы идентификации. Эти системы по своей сути поддерживают лучшие практики в управлении учетными данными, обеспечивая их передачу безопасными путями, часто с использованием отдельных каналов связи или методов для идентификаторов пользователей и механизмов аутентификации.

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

2.21 Отключаются и удаляются ли неактивные учетные записи пользователей после определенного периода бездействия?

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

Для наших клиентов мы пропагандируем использование Single Sign-On (SSO) и федеративных систем идентификации. Такой подход упрощает управление доступом. Например, когда клиент удаляет сотрудника из своей системы идентификации, доступ к Lokad одновременно прекращается. Этот метод не только повышает безопасность, но и обеспечивает эффективность управления пользователями.

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

3. Авторизация

3.1 Предоставляет ли решение детальные права доступа?

Да. Решение Lokad включает в себя детальную подсистему RBAC (контроль доступа на основе ролей). Это позволяет клиенту контролировать, к каким “Projects” и “Files” имеют доступ (и кем) в аккаунте Lokad. У RBAC есть свой веб-интерфейс (панель управления). Он доступен всем пользователям с обозначением “Owner” в аккаунте Lokad. Дополнительную информацию см. в нашей документации роли пользователей и разрешения.

3.2 Позволяет ли решение клиенту настраивать доступ в соответствии с принципом наименьших привилегий (PoLP)?

Да. Решение Lokad включает детальную подсистему RBAC (контроль доступа на основе ролей), которая может быть использована для реализации PoLP. Однако благодаря Envision (DSL решения) Lokad идет гораздо дальше, чем большинство корпоративного программного обеспечения по этому принципу.

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

3.3 Обязываете ли вы применять принципы наименьших привилегий?

Да, хотя то, что считается “наименьшей приемлемой” привилегией, в конечном итоге определяется нашими клиентами. Lokad не может в одностороннем порядке определить, кто должен иметь обозначение “Owner” в штате клиента. Однако мы можем предоставить рекомендации в этом отношении. На практике, для наших “управляемых” клиентов — тех, кого поддерживает команда Supply Chain Scientists от Lokad, — мы разъясняем (в письменной форме) требуемую организацию и соответствующие права доступа.

3.4 Обладает ли решение возможностью скрыть определенный объект в системе от назначенных пользователей?

Да. Это форма реализации принципа наименьших привилегий и подробно освещается в ответах 3.1, 3.2 и 3.3.

3.5 Существует ли классификация данных (по уровням чувствительности), и настроены ли меры контроля в соответствии с этой классификацией?

Да. Встроенно, Lokad по умолчанию ограничивает доступ ко всем административным данным (таким как список пользователей, имеющих учетную запись) для “Owners” аккаунта. Это обозначение является самым высоким и привилегированным в системе RBAC (контроль доступа на основе ролей). Все остальные данные в аккаунте Lokad могут быть сегментированы в соответствии с классификацией чувствительности, определяемой пользователем. Такая классификация может применяться как к исходным данным (загруженным клиентом), так и к преобразованным данным (результат преобразований, выполненных на платформе Lokad).

Для получения дополнительной информации о контроле доступа и обозначениях, пожалуйста, см. ответы 3.1, 3.2 и 3.3.

3.6 Может ли решение авторизовывать или блокировать пользователей/роли/транзакции в режиме реального времени?

Да, хотя термин “в режиме реального времени” требует уточнения в контексте распределённой компьютерной системы (как, например, в решении Lokad). Обновления системы RBAC (управление доступом на основе ролей) происходят синхронно, то есть становятся активными в течение нескольких секунд (обычно меньше). Заметных задержек (например, в течение часа или дня) нет.

Что касается прерывания транзакций, то это неактуально, поскольку у Lokad нет транзакционной базы данных. Однако Lokad может прерывать долгосрочные асинхронные операции (называемые в Lokad “запусками проектов”). Когда происходит прерывание, система немедленно (синхронно) гарантирует, что обработка не повлияет на систему, например, не перезапишет файлы. Однако отключение обработки является асинхронным и обычно вступает в силу в течение 20 секунд.

3.7 Ограничивает ли решение доступ к персональной идентифицируемой информации (PII) только для пользователей с соответствующим уровнем разрешений?

Да, хотя решение не предназначено для хранения каких-либо данных PII (за исключением идентификаторов аутентификации сотрудников, имеющих доступ к решению). Это относится как к Lokad, так и к клиенту. В системе доступ к списку пользователей имеют только сотрудники с назначением “Owner”. Для оптимизации цепочки поставок Lokad не нуждается в данных PII (и не получает от них выгоды), и наши договорные положения это предусматривают (подробнее см. Практики 1.4 и Практики 1.5).

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

3.8 Позволяет ли решение фильтры поиска данных PII запрещать использование подстановочных знаков?

Да. Однако пользователь с назначением “Owner” в аккаунте Lokad может получить доступ ко всем пользователям (включая сотрудников клиента), авторизованным для входа в аккаунт. Lokad не может ограничить эту возможность, поскольку наши клиенты должны иметь возможность полностью проверять список пользователей, имеющих доступ к их аккаунту.

3.9 Оснащена ли система технологией WAF (межсетевой экран для веб-приложений)?

Нет. WAF – по своей природе опасная архитектура, поскольку нарушает принцип “наименьших привилегий”: компоненту предоставляются огромные привилегии для работы в роли “человека посередине”. Это делает сам WAF основной мишенью для злоумышленников и значительно увеличивает поверхность атаки платформы. Однако Lokad тщательно отслеживает свой веб-трафик и аномальное поведение пользователей на собственной платформе. Эти возможности являются частью платформы, поэтому не делегируются привилегированным изолированным сторонним программным компонентам.

Смотрите также Employees 6.6.

3.10 Оснащена ли сеть технологией IPS (система предотвращения вторжений)?

Нет. IPS – по своей природе опасная архитектура, поскольку нарушает принцип “наименьших привилегий”: компоненту предоставляются огромные привилегии для работы в роли “человека посередине”. Это делает сам IPS основной мишенью для злоумышленников и значительно увеличивает поверхность атаки платформы. Чтобы усилить защиту платформы Lokad от вторжений, наша архитектура начинается с минимизации этой поверхности. Мы считаем, что гораздо безопаснее исключить возможности для вторжений на этапе проектирования, а не пытаться “предотвратить” их впоследствии.

Смотрите также Employees 6.6.

3.11 Использует ли сервис технологию защиты от DoS (атаки типа отказ в обслуживании)?

Да. Lokad использует ReCaptcha, ограничения скорости nginx и наши собственные специализированные компоненты (например, раннюю остановку при неверной аутентификации).

3.12 Осуществляется ли весь административный доступ к производственной среде через jump-хосты или bastion-сервера?

Да. У нас есть система, по сути аналогичная “Teleport”. Она обеспечивает не только полную трассируемость всех доступов, но и упрощает безопасное отзыв прав доступа у сотрудников.

3.13 Существует ли чёткий процесс авторизации для предоставления административного доступа (и обеспечивающий надёжный аудит)?

Да. Смотрите Logging and Monitoring 5.1 и 5.11.

3.14 Существует ли систематический и регулярный процесс пересмотра прав доступа (проводимый уполномоченным лицом), при котором административные права проверяются на соответствие изменившимся ролям и обязанностям?

Да. Существует два уровня административных прав доступа.

Первый уровень: административные права для поддержки инфраструктуры Lokad. Эти права предоставляются и контролируются IT-отделом Lokad.

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

3.15 Соответствует ли ваша политика ограничения доступа принципу “наименьших привилегий”, при котором разрешается только необходимый и одобренный трафик?

Да. Мы применяем принцип наименьших привилегий (PoLP) ко всем уровням доступа нашей инфраструктуры, включая сетевой трафик. Степень ограничений доступа варьируется в зависимости от конкретного случая. Например, для некоторых доступов разрешён вход только конкретному аутентифицированному пользователю с определённого IP-адреса. В других случаях доступ открыт для всех, как это происходит с содержимым нашей сети доставки контента (CDN).

Смотрите также Authorization 3.3.

3.16 Ограничены ли исходящие соединения из производственной среды?

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

Нашим производственным виртуальным машинам требуется доступ к нескольким внешним API. Большая часть этих API размещена на платформе Microsoft Azure, за исключением некоторых, например letsencrypt.org. Мы пришли к выводу, что поддержание строгого списка разрешённых IP-адресов создаст сложности, которые могут перевесить преимущества. Ограничение исходящих соединений может обеспечить ограниченные преимущества в плане безопасности, но также может внести сложности, которые потенциально подрывают безопасность нашей производственной среды.

3.17 Доступна ли для клиентов/пользователей коммуницированная форма связи (например, электронная почта, веб-форма, телефон и т.д.), работающая круглосуточно 24/7/365 для сообщения об инцидентах безопасности?

Да, мы внедрили стандарт security.txt для упрощения сообщения об инцидентах безопасности.

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

Наш файл security.txt расположен по адресу https://www.lokad.com/.well-known/security.txt и описывает актуальный процесс сообщения об инцидентах безопасности. Это гарантирует, что любой, будь то клиент, заказчик или исследователь безопасности, сможет легко найти соответствующие контактные данные и инструкции по сообщению о проблемах безопасности.

Обратите внимание, что, хотя процесс, изложенный в файле “security.txt”, может быть пересмотрен, самая актуальная и точная информация всегда будет доступна по указанному адресу. Мы обеспечиваем, чтобы каналы связи, указанные в файле — будь то электронная почта, веб-форма или иной способ — были укомплектованы персоналом и доступны 24/7/365 для оперативного реагирования на сообщения о безопасности.

4. Управление данными

4.1 Где вы размещаете и обрабатываете данные?

Наша платформа SaaS (программное обеспечение как услуга) на 100% размещена на Microsoft Azure; точнее, она находится в центре обработки данных Microsoft Azure Europe North (находящемся в Дублине). Наши резервные копии хранятся в центре обработки данных Microsoft Azure Europe West (находящемся в Амстердаме). В случае серьезного сбоя центра обработки данных у нас есть план по миграции платформы в Дублин. С момента нашей миграции на Microsoft Azure в 2010 году подобная ситуация не возникала. Все данные наших клиентов находятся в Европе и останутся там даже в случае масштабного сбоя центра обработки данных.

4.2 Кто является владельцем данных?

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

4.3 Управление базой данных осуществляется внутри компании или с привлечением внешних специалистов?

Управление слоем данных Lokad осуществляется инженерными командами Lokad. Как упоминалось ранее, основная платформа Lokad не включает транзакционную базу данных (см. Authorization 3.6), поскольку вместо этого используется хранилище событий. Это хранилище событий полностью реализовано и управляется Lokad.

4.4 Обладает ли решение возможностью переключаться между реляционной базой данных (PostgreSQL, Oracle, MySQL) и NoSQL базой данных (Cosmos)?

Теоретически да, но это не имеет практического значения, поскольку решение Lokad не использует RDBMS. Слой постоянного хранения данных в решении Lokad основан на хранилище событий и хранилище ключ-значение. Такой подход кардинально отличается от стандартного дизайна CRUD (создание, чтение, обновление, удаление), распространённого в корпоративном ПО. Поскольку Lokad является решением SaaS, мы полностью отвечаем за постоянство данных и их совместимость в будущем (чтобы обеспечить доступ к старым данным).

4.5 Привлекаются ли третьи стороны для работы решения?

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

4.6 Разделяете ли вы слои (сеть, серверы и приложения)?

Да, однако низкоуровневое управление сетями и серверами делегируется базовой облачной платформе, которую использует Lokad — Microsoft Azure. Таким образом, разделение слоёв сети и серверов в основном происходит вне периметра, управляемого Lokad. В рамках решения Lokad мы строго ограничиваем привилегии, предоставляемые прикладным слоям, чтобы они не могли управлять собственной инфраструктурой (например, прикладные слои не имеют прав на запись при управлении DNS).

4.7 Существует ли процесс, гарантирующий полное удаление данных?

Да, хотя выполнение всех этапов может занять несколько недель. Процесс включает подачу формального письменного запроса — от уполномоченного лица в организации клиента — на полное удаление соответствующих данных. На практике конкретные положения для таких запросов включены в договорное соглашение между Lokad и его клиентами. Сначала данные удаляются из нашей основной производственной системы, а затем из резервной системы. Последний этап и вызывает относительную “медлительность” операции. Это осознанный выбор, поскольку после удаления данных из основной системы доступ к ним невозможен (за исключением чрезвычайных процессов восстановления после катастроф).

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

4.8 Обладает ли решение возможностью мягкого удаления данных?

Да. Решение Lokad использует подход event sourcing. Таким образом, всё версиируется по умолчанию: как записи пользователей, так и изменения, внесённые в файловую систему Lokad. Все операции удаления в программном обеспечении являются мягкими, их можно отследить и при необходимости восстановить.

4.9 Предоставляете ли вы прямой доступ к базе данных?

Да, в том смысле, что к файловой системе — части решения Lokad — можно получить доступ через такие протоколы, как FTPS и SFTP. Этот доступ обширен, поскольку все данные, используемые в качестве входных или производимых в качестве выходных, хранятся в этой файловой системе.

Однако, поскольку у Lokad нет транзакционной базы данных, не существует базы данных, которую можно было бы сделать “доступной”. Ближайшим аналогом в архитектуре Lokad является наше хранилище событий, и мы не предоставляем прямой доступ к потоку событий. Тем не менее, в контрактном соглашении могут быть предусмотрены положения, позволяющие клиенту запросить определённые извлечения из этого потока (при наличии обоснованной необходимости).

4.10. Как решение интегрирует внешние данные?

Решение может использовать несколько протоколов для интеграции внешних данных, в том числе FTPS и SFTP. Также доступен веб-интерфейс для ручной загрузки файлов. Решение Lokad способно интегрировать любые разумно табличные данные. Для получения дополнительной информации о возможностях внешней интеграции данных Lokad смотрите Go to IT Perspective on Lokad 2.15.

4.11 Обладает ли система возможностью обрабатывать захват изменённых данных (CDC) из потоков данных в реальном времени?

Да, при наличии специального контрактного соглашения с клиентом. Захват изменённых данных (CDC) является шаблоном проектирования программного обеспечения, а не конкретным стандартом данных или протоколом передачи, и ожидания “в реальном времени” могут варьироваться от задержек менее миллисекунды до задержек менее минуты. Возможности в этой области следует оценивать с точки зрения цепочки поставок. По нашему опыту, потоки данных в режиме реального времени редко актуальны для решения проблем цепочки поставок.

4.12 Можно ли экспортировать все данные в рамках решения?

Да, все данные, доступные через файловую систему аккаунта Lokad, могут быть экспортированы с помощью таких протоколов, как FTPS или SFTP.

4.13 Предоставляет ли решение инструменты для экспорта данных?

Да, решение Lokad предлагает DSL (специализированный язык программирования), называемый Envision, предназначенный для аналитики цепочки поставок. Envision предоставляет обширные возможности для переформатирования данных в аккаунте Lokad.

4.14 Какой формат будут иметь экспортированные данные?

Платформа Lokad поддерживает все распространенные табличные форматы, включая CSV и XLS (Microsoft Excel). Платформа поддерживает множество параметров, касающихся формата чисел, дат, разделителей, кодировки текста, заголовков и т.д.

4.15 Предусмотрено ли в решении прозрачное шифрование данных (TDE) персональной информации (PII) как в мобильном, так и в бэкенд-хранилище?

Прозрачное шифрование данных используется как в бэкенд-хранилище Lokad (с использованием шифрования Azure Storage для данных в покое), так и на устройствах, выданных Lokad (с помощью BitLocker). Lokad не хранит PII на устройствах без включенного TDE.

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

Да. Все секреты на уровне платформы хранятся в Key Vault, сервисе, предоставляемом Microsoft Azure. Пароли пользователей дополнительно засолены и захешированы с использованием Scrypt согласно стандартным практикам.

4.17 Имеет ли решение возможность ограничивать загрузку файлов по типу и размеру, а также сканировать на наличие вредоносного контента?

Да, в некоторой степени. Что касается размера файла, оптимизация цепочки поставок часто требует обработки больших файлов. Эти размеры файлов отражают извлечение исторических бизнес-данных, которые мы в конечном итоге обрабатываем (например, исторические заказы продаж). Учитывая это, платформа Lokad поддерживает размеры файлов до 100 ГБ.

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

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

4.18 Каков рекомендуемый срок хранения данных?

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

4.19 Предоставляете ли вы документацию по структуре данных?

Да, в составе “Совместного руководства по процедурам”. Следует отметить, что в Lokad не используется реляционная база данных, в отличие от большинства корпоративного программного обеспечения. Вместо этого мы применяем парадигму event sourcing. Однако структуры данных, представляющие интерес для клиентской компании, находятся не в источнике событий, а во вспомогательных файлах, создаваемых с помощью скриптов Envision на платформе Lokad. Эти файлы разработаны в соответствии с конкретными требованиями клиентской компании. Документация для этих файлов включена в “Совместное руководство по процедурам” - один из результатов типичной инициативы Lokad.

4.20 Является ли сегментация данных других клиентов частью дизайна системы?

Да, хотя Lokad является приложением с несколькими арендаторами, данные разделены на уровне архитектуры между арендаторами, то есть клиентскими аккаунтами. Такая сегментация является первостепенной в нашем бэкенд-дизайне. Этот подход предотвращает ошибки программирования, которые могли бы раскрыть данные одного арендатора другому, даже при разработке рутинных функций платформы. Основное хранилище, используемое в Lokad – Blob Storage от Microsoft Azure – облегчает такое строгое разделение на уровне дизайна.

4.21 Предприняты ли эффективные меры для обеспечения того, чтобы данные клиентов не использовались в средах разработки и тестирования?

Да, по умолчанию команда разработчиков не имеет прямого доступа к данным клиентов. Мы разработали обширные тестовые среды и наборы “макетных” данных, чтобы обеспечить бесперебойную работу команды разработчиков без доступа к реальным данным клиентов. Lokad также использует собственную платформу для анализа данных (например, для анализа детального потребления облачных вычислительных ресурсов, полученных от Microsoft Azure). Такая практика “dogfooding” гарантирует, что у Lokad всегда имеется достаточное количество некритичных данных для разработки и тестирования.

Однако мы разработали специальный ограниченный канал для доступа к минимальным (только для чтения) фрагментам данных клиентов в диагностических целях. Этот канал автоматически обеспечивает строгое и полностью автоматизированное минимизирование извлекаемых данных. Также этот канал автоматически обеспечивает удаление данных по завершении диагностической операции. См. 4.22 для получения дополнительной информации об этом ограниченном канале.

4.22 Если для разработки или тестирования требуется ограниченное использование данных клиентов, существует ли определенный процесс для обеспечения безопасного и полного уничтожения данных в средах разработки и тестирования?

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

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

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

4.23 Известны и задокументированы ли все физические местоположения данных клиентов, включая системы резервного копирования и высокодоступности?

Да. Все данные клиентов хранятся в физически защищенных дата-центрах Microsoft Azure, включая резервные копии. Мы не храним данные клиентов локально (то есть на территории Lokad), и данные клиентов не сохраняются на устройствах сотрудников.

4.24 Ограничен ли доступ к физическим серверам только сотрудниками, которым это необходимо для выполнения их работы?

Да, хотя данные клиентов Lokad хранятся в безопасных дата-центрах Microsoft Azure — местоположении, к которому Lokad не имеет физического доступа. Физическое местоположение дата-центров Microsoft является общедоступной информацией, а выбор дата-центров Lokad также документирован в публичном доступе.

4.25 Хранится ли основной номер счета (PAN) только в случае, если это абсолютно необходимо для законных бизнес-целей?

Lokad не получает, не хранит и не управляет никакими PAN клиентов.

PAN (Основной номер счета) обычно относится к основному номеру на кредитной или дебетовой карте. Это последовательность цифр, выпукло или напечатана на лицевой стороне карты и используется для уникальной идентификации банковского счета, связанного с картой.

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

У нас есть несколько PAN — для собственных карт Lokad — которые мы управляем безопасно, следуя инструкциям, предоставленным самими банками.

4.26 Никогда ли не отправляются незашифрованные основные номера счетов (PAN) с помощью технологий обмена сообщениями конечных пользователей (например, по электронной почте, через мгновенные сообщения и чаты)?

Да, незашифрованные PAN (Основные номера счетов) никогда не передаются через ненадежные каналы, такие как электронная почта. Lokad предоставляет встроенный защищенный канал коммуникации на своей платформе, который является более надежной альтернативой для передачи конфиденциальной информации. Мы рекомендуем использовать этот канал, когда применение ненадежного канала представляет значительный бизнес-рисок.

Примечание: Согласно архитектуре, Lokad не получает, не хранит и не управляет PAN клиентов. Следовательно, незашифрованные передачи PAN отсутствуют.

См. также хранение PAN

4.27 Имеется ли у вас контракт с поставщиком(ами) облачных вычислительных услуг, и содержит ли этот контракт положения, касающиеся мер информационной безопасности поставщика(ов) облачных услуг?

Да, у Lokad имеется корпоративное соглашение (Enterprise Agreement, EA) с Microsoft на услуги облачных вычислений Azure. Корпоративное соглашение обычно включает различные условия, касающиеся использования услуг, включая обязательства по безопасности облачной среды.

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

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

4.28 Участвуют ли субподрядчики в обработке данных/деталей клиентов?

Нет, Lokad не передает обработку данных или деталей клиентов субподрядчикам. Что касается платформы Lokad, мы приобретаем вычислительные ресурсы — в основном виртуальные машины и blob-хранилище — у Microsoft Azure, но кроме этого ни одна третья сторона не участвует в обработке данных клиентов.

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

Примечание: Стажеры подписывают такие же соглашения о конфиденциальности, как и штатные специалисты по цепочке поставок.

5. Логирование и мониторинг

5.1 Предоставляете ли вы журналы доступа (пользователь, дата, дата последнего подключения и т.д.)?

Да. Lokad предоставляет журналы доступа в формате CSV. На данный момент эти журналы можно запросить у службы поддержки Lokad. Извлеченные журналы будут размещены в аккаунте Lokad в разделе, доступном только пользователям с правами “Owner”. Мы планируем внедрить более прямой метод доступа — через специализированный веб-интерфейс — к полной аудиторской записи, которая уже существует в бэкенде платформы Lokad.

5.2 Централизуете ли вы журналы всех компонентов решения?

Да. Архитектура на основе event sourcing в Lokad централизует не только журналы, но и все изменения состояния, происходящие в решении. Журналы, вместе с другими изменениями состояния, централизованы в виде небольшого набора потоков событий, управляемых одним и тем же хранилищем событий. Внутри системы журналы, не влияющие на состояние решения, разделяются от тех, что оказывают влияние.

С технической точки зрения, существуют журналы, связанные с производительностью, которые намеренно не централизуются в хранилище событий. Эти журналы включают детальные замеры производительности, такие как время, затраченное (в миллисекундах) на каждый вызов функции во время выполнения скрипта Envision. Эти журналы производительности не содержат информации, которую можно было бы квалифицировать как «связанную с безопасностью».

5.3 Логируете ли вы изменения и операции, выполняемые в приложении? Фиксируете ли вы все транзакции?

Да. Благодаря архитектуре event sourcing в Lokad, все обязательно логируется. Фактически, само решение является суммой набора событий, записанных в системе. Таким образом, логирование является фундаментальным аспектом архитектуры решения. Такая архитектура event sourcing предотвращает случайное пропускание записи, отражающей изменение состояния. В рамках такой архитектуры нет транзакций, по крайней мере, в обычном смысле транзакционной базы данных (например, MySQL, Oracle и т.д.). Эти транзакции заменены событиями, содержащими всю информацию, связанную с изменением состояния.

5.4 Нормализуете ли вы форматы журналов различных компонентов для целей судебной экспертизы?

Да. “Журналы”, с точки зрения аудита и/или безопасности, представляют собой преобразования исходных событий. События представляют собой сериализованные объекты. Для получения журналов решение Lokad конвертирует и компилирует эти события в CSV-файлы. Мы нормализуем форматы дат, числовые форматы и идентификаторы пользователей, используемые при извлечении в CSV.

5.5 Предоставляете ли вы экспорт журналов сторонним организациям через какой-либо протокол запросов?

Да, на условиях контрактного соглашения с клиентом.

5.6 Отслеживаете ли вы все исключения, возникающие в вашем решении?

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

5.7 Имеет ли решение возможность мониторить состояние различных компонентов/сервисов в реальном времени?

Да. Наши подсистемы разработаны с контрольными точками мониторинга, предназначенными для проверки работоспособности. У нас есть инструменты мониторинга, доступные только – по состоянию на январь 2023 – для инженерных команд Lokad, которые непрерывно собирают данные, предоставляемые этими контрольными точками.

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

5.8 Имеет ли решение возможность интегрировать сторонние инструменты мониторинга? Поддерживает ли решение SNMP или JMX, или возможность отправлять SNMP и JMX события в сторонние системы мониторинга?

Да, при условии наличия специального договорного соглашения.

5.9 Имеет ли решение возможность мониторинга пакетных заданий, которые не начали выполняться по расписанию, и их завершения?

Да. Решение Lokad имеет свой собственный внутренний планировщик задач (называемый “Runflow”) для оркестрации длительных задач в рамках платформы Lokad — обычно выполнения скриптов Envision. Этот планировщик может быть настроен через веб-интерфейс для указания расписания и временных рамок выполнения последовательности заданий.

5.10 Имеет ли решение возможность генерировать проактивные оповещения? Обладает ли оно способностью к корреляции и анализу ошибок, а затем предпринять проактивные действия?

Да. Runflow, планировщик задач решения, может предупредить клиента/Lokad о том, что текущая последовательность выполнения задерживается. Оповещение может быть отправлено до завершения последовательности. Решение Lokad предлагает обширные возможности через Envision (его DSL) для анализа и самодиагностики ситуаций с целью принятия проактивных мер. Хотя платформа Lokad предоставляет эту возможность, она все же требует участия инженера для реализации — через Envision — фактической логики, поскольку ситуации в цепочке поставок, квалифицируемые как “ошибки”, могут различаться.

5.11 Имеет ли решение возможности хранения аудита данных? Архивируются ли данные и очищаются ли они в базе данных MIS для аудита активности пользователей?

Да. Благодаря использованию модели источника событий, решение Lokad сохраняет обширный журнал аудита; гораздо более подробный, чем тот, который получается при использовании более традиционных подходов с транзакционной базой данных вместо хранилища событий. Решение Lokad не выделяет систему управления информацией (MIS) как отдельную подсистему. Фактически, поток событий является журналом аудита. Более того, Lokad сохраняет производственные данные на протяжении всего срока оказания услуг клиенту. По окончании обслуживания, что зависит от согласованных договорных условий, данные клиента очищаются, хотя окончательное удаление из системы резервного копирования может произойти через несколько месяцев после окончания контракта.

5.12 Интегрирована ли в вашу систему система самонаблюдения (технического и функционального характера)?

Да, платформа Lokad интегрирует несколько механизмов самонаблюдения на различных уровнях.

Облачная платформа контролируется командами инженеров по программному обеспечению Lokad. Поскольку платформа Lokad является многоарендной, этот мониторинг в значительной степени выполняется с системной точки зрения, обеспечивая соответствие возможностей платформы (включая её профиль производительности) установленным стандартам. Мы разработали собственный слой инструментализации для этой цели. “Функциональный” мониторинг, как правило, специфичен для клиента, поскольку зависит от особенностей конкретной цепочки поставок. Этот мониторинг обычно обеспечивается командами специалистов по цепочке поставок (инженерами от Lokad) в соответствии с договоренностью.

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

5.13 Проводится ли своевременный и систематический анализ логов для обнаружения отклонений и признаков нарушения?

Да. Ежедневный анализ текущей активности платформы Lokad входит в наши рутинные задачи. Дизайн нашей платформы способствует этому процессу.

См. также Logging and Monitoring 5.2.

5.14 Управляются ли системы управления логами людьми, не участвующими в администрировании других систем (т.е. обеспечивается разделение обязанностей)?

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

5.15 Проводятся ли на регулярной и систематической основе сканирования уязвимостей на уровне приложений?

Да, хотя такие сканирования составляют очень малую часть наших процессов по обеспечению безопасности. См. Employees 6.6.

5.16 Существует ли определенный процесс для периодического пересмотра действующих правил брандмауэра?

Да, наша производственная машина работает согласно очень строгим правилам, таким как открытие крайне ограниченного количества портов (настраивается через Microsoft Azure). Конфигурация нашей инфраструктуры автоматизирована, и её изменения проходят через наш стандартный процесс ревью кода. Такая практика не только облегчает периодические проверки, но и снижает необходимость ручного пересмотра правил.

5.17 Оснащена ли сеть технологией IDS (система обнаружения вторжений)?

Нет. IDS по своей сути представляет опасную конструкцию, так как нарушает принцип “наименьших привилегий”: компоненту предоставляются огромные права для функционирования в роли “человека посередине”. Это делает саму систему IDS привлекательной целью для злоумышленников и значительно расширяет поверхность атаки платформы. Однако Lokad тщательно контролирует свой веб-трафик и аномальное поведение пользователей на нашей собственной платформе. Эти возможности являются неотъемлемой частью платформы и, таким образом, не передаются привилегированным изолированным сторонним программным компонентам.

См. также Employees 6.6.

6. Сотрудники

6.1 Имеют ли сотрудники соглашения о неразглашении (NDA)?

Да, все сотрудники Lokad подпадают под условие NDA в своих трудовых контрактах.

6.2 Проходят ли сотрудники обучение по вопросам осведомленности о безопасности и тренинги по безопасности?

Да, обучение по вопросам осведомленности о безопасности и тренинги по безопасности проводятся для сотрудников Lokad, которые имеют дело с конфиденциальными данными и/или с инженерными системами, работающими с конфиденциальными данными. Для получения дополнительной информации по этому вопросу, лекция Cybersecurity for Supply Chain посвящена специалистам по цепочке поставок — тем, кто работает с конфиденциальными данными клиентов.

6.3 Кто имеет доступ к данным клиентов в Lokad?

Клиент явно определяет список пользователей, имеющих доступ к его аккаунту в Lokad. Эти пользователи, в зависимости от настроенных прав доступа в аккаунте Lokad, могут иметь доступ к различным категориям данных клиента. В решении Lokad существует веб-приложение, предназначенное для управления правами доступа (называется “Hub”).

Со стороны Lokad для каждого клиентского аккаунта существует краткий список сотрудников, имеющих доступ. В первую очередь, этот список включает специалистов по цепочке поставок (инженеров от Lokad), которые реализуют и поддерживают решение по оптимизации цепочки поставок. От специалистов по цепочке поставок ожидается ежедневный доступ к данным клиента. Внутренне Lokad ограничивает доступ к клиентским аккаунтам только специалистами по цепочке поставок, назначенными для этих аккаунтов. Т.е. специалист по цепочке поставок A не может получить доступ к клиентскому аккаунту B, если ему явно не было назначено управление этим аккаунтом (согласно договоренности с клиентом).

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

6.4 Как вы обеспечиваете безопасность рабочих станций сотрудников?

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

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

6.5 Как обеспечивается безопасность смартфонов сотрудников?

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

6.6 Используете ли вы антивирус?

Да, на наших рабочих станциях установлен Microsoft Defender, согласно настройкам Microsoft Windows 10+. У нас нет другого антивируса помимо Microsoft Defender, но наша позиция такова, что этот класс инструментов зачастую приносит больше вреда, чем пользы (с точки зрения компьютерной безопасности). В качестве анекдотического примера, взлом SolarWinds в 2020 году считается одной из крупнейших катастроф в области компьютерной безопасности, и он был вызван программным обеспечением, которое предполагалось для улучшения безопасности. Более того, почти все программные продукты, предназначенные для обеспечения безопасности, требуют довольно высоких системных привилегий. В результате такие продукты становятся собственными векторами атаки. Наш взгляд на компьютерную безопасность таков: меньше — значит больше, и добавление очень сложных технологических компонентов в нашу прикладную среду почти неизбежно делает её менее безопасной, а не более надежной.

6.7 Проходят ли разработчики программного обеспечения периодическое обучение методам оценки угроз, стандартам безопасного кодирования, известным чек-листам безопасности и фреймворкам?

Да. Однако большинство известных чек-листов в первую очередь отражают архитектуры, которые “ненадежны по замыслу”. При любой возможности мы предпочитаем устранять источник проблем с безопасностью еще на этапе проектирования. См. также Employees 6.2.

6.8 Включают ли все контракты с субподрядчиками/внешними сотрудниками Lokad соглашение о неразглашении (NDA)? Покрывает ли это соглашение информацию о клиентах?

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

Однако, если Lokad сочтет необходимым привлечь субподрядчика, он будет подчиняться тем же условиям по интеллектуальной собственности (IP) и соглашениям о неразглашении (NDA), что и наши постоянные сотрудники. Эти соглашения включают положения, касающиеся информации о клиентах Lokad.

6.9 Пройдена ли всей внешней рабочей силой Lokad внутренняя вводная подготовка по информации и безопасности (а также последующее соответствующее обучение)?

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

Однако, если Lokad сочтет необходимым привлечь внешнюю рабочую силу, это станет обязательным требованием. Все субподрядчики/внешние работники будут подчиняться тем же требованиям по безопасности и условиям обучения, что и наши постоянные сотрудники.

Как уже было отмечено, в настоящее время Lokad не полагается на внешнюю рабочую силу, поэтому подобное обучение не проводится.

См. также Employees 6.8

6.10 Включают ли все контракты с компаниями, предоставляющими внешнюю рабочую силу для Lokad (все подрядчики, консультанты и т.д., участвующие в предоставлении услуг Lokad), требование проведения проверки на наличие судимостей? Соответствуют ли эти проверки уровню доступа к информации и критичности роли сотрудника?

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

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

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

6.11 Отключаются или удаляются ли административные аккаунты автоматически по окончании трудоустройства?

Да. Все сотрудники Lokad получают свои права доступа через федеративного поставщика идентификационных услуг (Microsoft Azure Active Directory). По окончании трудоустройства, если применимо, этот доступ отзывается, автоматически отключая все связанные административные права.

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

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

Да, проверки на наличие судимостей проводятся строго в соответствии с требованиями выполняемой работы.

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

6.13 Какие меры предосторожности принимает Lokad для обеспечения того, чтобы неавторизованный персонал не мог получить доступ к помещению, где выполняется работа?

На уровне здания, Lokad работает в офисном здании, которое обеспечивает круглосуточное (24 часа в сутки, 7 дней в неделю) видеонаблюдение сторонней организации с охраной на месте.

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

Примечание: любые исключительные посетители (например, клиенты, потенциальные кандидаты и т.д.) должны быть физически встречены и допущены сотрудниками Lokad.

6.14 Разрешен ли доступ посетителям в помещения?

Если «фасилити» означает «место, где хранятся и обрабатываются данные клиентов», то нет. Данные клиентов хранятся в дата-центрах Microsoft Azure. Эти дата-центры не доступны для публики — сам Lokad не может получить к ним доступ.

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

6.15 Хранятся ли бумажные записи данных (и переносимые электронные носители, содержащие данные) в надежных огнестойких шкафах на ночь?

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

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

6.16 Существует ли политика «чистого стола»? Если да, то в какой мере?

Да, в Lokad строго соблюдается политика «чистого стола». Эта политика реализована «по замыслу» через нашу цифровую среду.

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

Таким образом, в конце рабочего дня у сотрудников Lokad не остается ничего to clear. Как только компьютерная сессия сотрудника заблокирована — политика, которую мы строго соблюдаем — его рабочее место фактически очищается.

6.17 Куда поступают факсы и кто может получить к ним доступ?

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

6.18 Существует ли процедура проверки возврата составляющих активов (компьютеров, мобильных телефонов, пропусков, токенов, смарт-карт, ключей и т.д.) при увольнении?

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

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

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

6.19 Утверждены ли руководством политики и/или процедуры в области управления персоналом (HR) и доведены до сведения заинтересованных сторон, и назначен ли ответственный за их поддержку и пересмотр?

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

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

6.20 Используются ли личные (BYOD) мобильные устройства, а не принадлежащие компании, сотрудниками вашей организации, имеющими доступ к данным клиентов?

Нет, Lokad не разрешает доступ к данным клиентов с личных (BYOD) мобильных устройств. Мы предоставляем нашим сотрудникам высококачественное оборудование, принадлежащее компании, что исключает необходимость использования личных устройств. Это решение устраняет распространенную ситуацию, когда сотрудники прибегают к использованию собственных устройств из-за неудовлетворенности низким качеством оборудования компании.

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

Примечания