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

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

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

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

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

Безопасность, заложенная в архитектуре

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

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

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

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

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

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

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

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

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

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

1. Практики

1.1 Применяете ли вы практики обеспечения безопасности?

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

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

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

В разработке ПО безопасность обычно достигается сокращением лишнего, а не наращиванием мер; работой инженеров, специализирующихся на безопасности, а не созданием дополнительных команд неспециалистов. Вспомним такие катастрофы, как Heartbleed или Log4Shell. Их, вероятно, удалось бы предотвратить, если бы тысячи «сертифицированных» компаний отдавали приоритет проверке стороннего кода, часто становящегося источником проблем, вместо погони за произвольно выбранными коммерческими знаками одобрения.

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

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

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

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

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

Безопасность базы данных: В слое хранения Lokad нет реляционной базы данных: только два непрограммируемых компонента — хранилище событий и хранилище «ключ — значение». Это архитектурное решение полностью устраняет необходимость в проверках базы данных.

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

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. Мы работаем по модели SaaS, однако договоры некоторых крупных клиентов позволяют запрашивать полные снимки нашей кодовой базы. Их депонируют у согласованной третьей стороны. Если Lokad прекратит деятельность, клиент автоматически получит доступ к коду и лицензию с широкими правами, позволяющую воссоздать собственный экземпляр сервиса.

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

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

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

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

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

Мы используем архитектуру Zero Trust: доступ к данным получают только те, у кого есть соответствующее право в данный момент. Само нахождение в нашей сети не даёт ни особого статуса, ни привилегий (см. Аутентификация 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 для лицензий, услуг, поддержки, обслуживания и обучения?

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

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. Даже инженерная команда не имеет незащищённого локального доступа к системам в эксплуатации. Положение внутри сети не позволяет обходить меры безопасности.

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. Для неё в системе 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 Предоставляет ли решение детальные права доступа?

Да. Подсистема RBAC (управление доступом на основе ролей) позволяет детально определять, кто имеет доступ к тем или иным проектам (Projects) и файлам (Files) в аккаунте Lokad. У неё есть собственная веб-панель, доступная всем пользователям с ролью «Owner». Подробности приведены в документации о ролях и правах пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

Прерывание транзакций здесь неактуально: у 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 по своей природе опасна: она нарушает принцип наименьших привилегий, предоставляя компоненту огромные полномочия для работы в роли посредника («man-in-the-middle»). Сам WAF становится привлекательной целью для злоумышленников и существенно расширяет поверхность атаки. Lokad внимательно отслеживает веб-трафик и аномальное поведение пользователей, но эти функции встроены в платформу, а не переданы отдельному стороннему компоненту с высокими привилегиями.

См. также Сотрудники 6.6.

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

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

См. также Сотрудники 6.6.

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

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

3.12 Осуществляется ли весь административный доступ к рабочей среде через промежуточные серверы (jump hosts или bastion hosts)?

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

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

Да. См. Журналирование и мониторинг 5.1 и 5.11.

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

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

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

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

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

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

См. также Авторизация 3.3.

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

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

Виртуальным машинам рабочей среды нужен доступ к нескольким внешним 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. Как отмечено в разделе Авторизация 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 являются логическими, а не окончательными. Это защищает от целых классов проблем, например случайного удаления данных сотрудником клиента или намеренного удаления злоумышленником. Намеренно медленный процесс окончательного удаления также снижает риск социальной инженерии, когда атакующий выдаёт себя за сотрудника клиента.

4.8 Поддерживает ли решение логическое удаление данных?

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

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

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

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

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

Данные можно загружать по нескольким протоколам, в том числе FTPS и SFTP, или вручную через веб-интерфейс. Lokad может принимать любые данные в разумно организованной табличной форме. Подробнее см. 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, — так и на выданных сотрудникам устройствах с помощью BitLocker. Lokad не хранит персональные данные на устройствах, где TDE не включено.

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

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

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

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

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

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

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

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

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

Да, в составе «Совместного руководства по процедурам». В отличие от большинства корпоративного ПО, Lokad использует не реляционную базу данных, а событийную архитектуру (event sourcing). Однако интересующие клиента структуры находятся не в хранилище событий, а в плоских файлах, создаваемых скриптами Envision. Эти файлы проектируются под конкретные требования клиента. Их документация входит в «Совместное руководство по процедурам» — один из обычных результатов проекта Lokad.

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

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

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 не передаёт обработку клиентских данных или сведений о клиентах субподрядчикам. Для платформы мы приобретаем вычислительные ресурсы, главным образом виртуальные машины и blob-хранилище, у Microsoft Azure. Другие третьи стороны данные клиентов не обрабатывают.

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

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

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

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

Да. Журналы доступа предоставляются в формате CSV; сейчас их можно запросить у службы поддержки Lokad. Выгрузка размещается в аккаунте в разделе, доступном только пользователям с ролью «Owner». Мы планируем предоставить более прямой доступ через специальный веб-интерфейс к полному журналу аудита, который уже ведётся в серверной части платформы.

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

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

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

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

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

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

Да. Журналы для аудита и безопасности получаются преобразованием исходных событий — сериализованных объектов. Lokad преобразует эти события и собирает их в 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 сохранять обширный журнал аудита, гораздо подробнее обычного журнала в системе с транзакционной базой данных. Управленческая информационная система (MIS) не выделена в отдельную подсистему: сам поток событий служит журналом аудита. Данные рабочей среды хранятся в течение всего срока обслуживания клиента. По завершении обслуживания их удаляют в соответствии с согласованными условиями договора, хотя окончательное удаление из резервных копий может занять ещё несколько месяцев.

5.12 Есть ли встроенные средства технического и функционального самоконтроля?

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

За облачной платформой следит инженерная команда Lokad. Поскольку она обслуживает разных клиентов, мониторинг ведётся преимущественно на системном уровне: проверяется, что функции и производительность отвечают требуемому уровню. Для этого мы разработали собственные средства измерений. Функциональный мониторинг обычно индивидуален для клиента, поскольку зависит от его цепочки поставок. Его обеспечивает команда специалистов по цепочке поставок Lokad в рамках договорённости с клиентом.

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

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

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

См. также Журналирование и мониторинг 5.2.

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

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

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

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

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

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

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

Нет. Архитектура IDS по своей природе опасна: она нарушает принцип наименьших привилегий, предоставляя компоненту огромные полномочия для работы в роли посредника («man-in-the-middle»). Сама IDS становится привлекательной целью для злоумышленников и существенно расширяет поверхность атаки. Lokad внимательно отслеживает веб-трафик и аномальное поведение пользователей, но эти функции встроены в платформу, а не переданы отдельному стороннему компоненту с высокими привилегиями.

См. также Сотрудники 6.6.

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

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

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

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

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

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+. Других антивирусов у нас нет. Мы считаем, что этот класс инструментов зачастую приносит безопасности больше вреда, чем пользы. Отдельный показательный пример — взлом SolarWinds в 2020 году, одна из крупнейших катастроф компьютерной безопасности, причиной которой стало ПО, предназначенное для её повышения. Почти все защитные программные продукты требуют высоких системных привилегий и сами становятся векторами атаки. Наш принцип — «меньше значит лучше»: добавление крайне сложных компонентов в прикладную среду почти наверняка снижает её безопасность.

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

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

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

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

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

6.9 Проходит ли весь внешний персонал вводное и последующее обучение внутренним правилам работы с информацией и безопасности Lokad?

На момент написания Lokad не привлекает субподрядчиков или внешний персонал. Разработчики ПО и специалисты по цепочке поставок состоят в прямых бессрочных трудовых отношениях с Lokad и работают под её руководством.

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

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

См. также Сотрудники 6.8.

6.10 Требуют ли договоры с поставщиками внешнего персонала — подрядчиков, консультантов и других участников оказания услуг 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 является полностью цифровой.

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

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

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

6.18 Проверяется ли при увольнении возврат выданного имущества — компьютеров, телефонов, пропусков, токенов, смарт-карт, ключей и т. д.?

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

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

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

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

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

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

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

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

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

Примечания