Безопасность

Безопасность в SecureCodingHub

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

SecureCodingHub управляется компанией LimePlate, Inc. Как компания, обучающая разработчиков писать безопасный код, мы предъявляем к себе высочайшие стандарты безопасности. Наша платформа построена на архитектуре security-first, а наши практики непрерывно пересматриваются и совершенствуются.

Безопасность инфраструктуры

Шифрование в покое

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

Шифрование при передаче

Все коммуникации между клиентами и нашими серверами используют TLS 1.3. Мы принудительно применяем HTTPS на всех эндпоинтах с заголовками HSTS и мониторингом прозрачности сертификатов.

Изоляция арендаторов

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

Аутентификация и доступ

SSO и SAML 2.0

Корпоративные клиенты могут интегрироваться со своим поставщиком идентификации, используя единый вход на основе SAML 2.0. Мы поддерживаем все основные IdP, включая Azure AD, Okta и OneLogin.

Многофакторная аутентификация

Поддержка MFA добавляет дополнительный уровень защиты учётных записей пользователей. Мы поддерживаем приложения-аутентификаторы на основе TOTP для второго фактора верификации.

Управление сессиями

Сессии криптографически защищены короткоживущими токенами, автоматическим истечением срока и возможностями отзыва. Неактивные сессии прекращаются по истечении настраиваемого тайм-аута.

Комплаенс

В процессе

SOC 2 Type II

Мы активно работаем над получением сертификации SOC 2 Type II. Наши средства контроля безопасности, доступности и конфиденциальности спроектированы в соответствии с Trust Services Criteria.

Соответствует

GDPR

Мы соблюдаем Общий регламент ЕС по защите данных (GDPR). Мы предоставляем соглашения об обработке данных, поддерживаем права субъектов данных и обеспечиваем правовые основания для обработки.

Соответствует

CCPA

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

Управление уязвимостями

Регулярное тестирование на проникновение

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

Сканирование зависимостей

Наш конвейер CI/CD включает автоматизированное сканирование зависимостей и анализ состава программного обеспечения. Известные уязвимости в сторонних библиотеках помечаются и оперативно устраняются.

Программа ответственного раскрытия

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

Обработка данных

Минимальный сбор данных

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

Политики хранения

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

Право на удаление

Пользователи могут запросить удаление своей учётной записи и связанных с ней данных в любое время. Мы оперативно обрабатываем запросы на удаление и подтверждаем выполнение в течение 30 дней.

Ответственное раскрытие

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

Сообщить на
security@securecodinghub.com
Подтверждение получения
В течение 48 часов
Первичная оценка
В течение 5 рабочих дней

Рекомендации

  • Предоставьте подробное описание уязвимости и шаги для её воспроизведения
  • Дайте нам разумное время для расследования и устранения проблемы до публичного раскрытия
  • Не получайте доступ, не изменяйте и не удаляйте данные других пользователей в ходе Вашего исследования
  • Не проводите тестирование на отказ в обслуживании и атаки социальной инженерии

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

Управление изменениями

Каждое изменение в продакшене проходит через ревью pull request с участием как минимум одного инженера за пределами непосредственной рабочей пары автора. CI выполняет модульные, интеграционные и проверки безопасности при каждом push. Деплои в продакшен проходят через отдельный шаг утверждения. Экстренные изменения следуют документированной процедуре break-glass с ретроспективным разбором на той же неделе. Изменения инфраструктуры управляются как код и пересматриваются по тому же рабочему процессу, что и код приложения.

Частота сканирования зависимостей

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

Регламент реагирования на инциденты

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

Что мы просим от клиентов

Ответственное раскрытие

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

Минимум привилегий на уровне аккаунта

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

Прекращение работы

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

Что мы публикуем и что нет

Публикуется

Страница статуса, охватывающая доступность платформы и инциденты деградации сервиса. Список субобработчиков. Текущее дополнение об обработке данных. Сама эта страница безопасности. Как только SOC 2 Type II будет завершён, отчёт будет доступен под NDA по запросу через Вашего контактного менеджера. Существенные обновления политик, затрагивающие клиентов, объявляются через Вашего контактного менеджера, а не прячутся в журнале изменений.

Не публикуется

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

Безопасность в SecureCodingHub: часто задаваемые вопросы

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

Где находится политика безопасности приложений SecureCodingHub?

Наша политика безопасности приложений реализуется главным образом через инженерные практики, описанные на этой странице, а не как отдельный маркетинговый артефакт. Каждое изменение в продакшене проходит через ревью pull request и конвейер CI, который выполняет модульные, интеграционные и проверки безопасности. Сканирование зависимостей выполняется на каждом pull request и снова ночью против основной ветки. Политика безопасности приложений, которую Ваша команда закупок, скорее всего, запрашивает, входит в пакет SOC 2 Type II, над которым мы работаем, и может быть передана под NDA по запросу.

Как SecureCodingHub подходит к комплаенсу информационной безопасности?

Комплаенс информационной безопасности здесь — на уровне продукта, а не для галочки. Мы активно работаем над SOC 2 Type II с мерами контроля, спроектированными вокруг Trust Services Criteria по безопасности, доступности и конфиденциальности. Мы уже работаем в соответствии с GDPR и CCPA, поддерживаем соглашения об обработке данных и соблюдаем права субъектов данных. Позицию по комплаенсу, которую Вы можете проверить уже сегодня, задокументирована на этой странице и в дополнении об обработке данных; сам отчёт SOC 2 будет доступен под NDA через Вашего контактного менеджера по завершении аудита.

Публикуете ли Вы полную политику информационной безопасности?

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

Как выглядит политика безопасности данных SecureCodingHub на практике?

Наша политика безопасности данных — это минимальный сбор по умолчанию и минимум привилегий по дизайну. Данные в покое шифруются AES-256 с использованием ключей, управляемых через выделенную службу управления ключами, а данные при передаче используют TLS 1.3 с принудительным HSTS. Данные клиентов логически изолированы на уровне приложения, поэтому утечки между арендаторами невозможны. Мы храним данные только в течение необходимого времени, поддерживаем инициированное пользователем удаление в течение 30 дней и никогда не продаём пользовательские данные третьим лицам.

Вопросы о нашей безопасности?

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

security@securecodinghub.com