Безопасность в SecureCodingHub
Мы создаём программное обеспечение для обучения безопасности. К собственной безопасности мы относимся столь же серьёзно. Здесь рассказывается, как мы защищаем Ваши данные и нашу инфраструктуру.
SecureCodingHub управляется компанией LimePlate, Inc. Как компания, обучающая разработчиков писать безопасный код, мы предъявляем к себе высочайшие стандарты безопасности. Наша платформа построена на архитектуре security-first, а наши практики непрерывно пересматриваются и совершенствуются.
Безопасность инфраструктуры
Все данные в покое зашифрованы с использованием AES-256. Тома баз данных, резервные копии и файловое хранилище шифруются ключами, управляемыми через выделенную службу управления ключами.
Все коммуникации между клиентами и нашими серверами используют TLS 1.3. Мы принудительно применяем HTTPS на всех эндпоинтах с заголовками HSTS и мониторингом прозрачности сертификатов.
Данные клиентов логически изолированы на уровне приложения. Данные каждой организации сегрегируются строгими средствами контроля доступа, что исключает утечки данных между арендаторами.
Аутентификация и доступ
Корпоративные клиенты могут интегрироваться со своим поставщиком идентификации, используя единый вход на основе 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, мы призываем Вас сообщить о ней ответственно.
Рекомендации
- Предоставьте подробное описание уязвимости и шаги для её воспроизведения
- Дайте нам разумное время для расследования и устранения проблемы до публичного раскрытия
- Не получайте доступ, не изменяйте и не удаляйте данные других пользователей в ходе Вашего исследования
- Не проводите тестирование на отказ в обслуживании и атаки социальной инженерии
Практики операционной безопасности
Каждое изменение в продакшене проходит через ревью 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