Безопасность данных

Шифрование

Все данные защищены отраслевым стандартом шифрования:

Инфраструктура

• Размещено на AWS (регион США)
• Приложение и база данных в изолированных сетях
• Регулярные обновления безопасности и патчи
• Защита от DDoS через AWS Shield
• Автоматизированный мониторинг и оповещения

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

Вот какие данные мы храним и зачем:

Соответствие

• Соответствие GDPR — обработка данных на основе законного интереса / контракта
• Пользователи могут запросить экспорт или удаление данных
• Хранение данных: активные учётные записи хранятся бессрочно, удалённые учётные записи очищаются через 90 дней
• Субпроцессоры перечислены в нашей политике конфиденциальности

Контроль доступа

• Ролевой контроль доступа внутри каждой организации (org_admin и learner)
• Изоляция данных на уровне организации (мультитенантность) — каждая запись несёт область organizationId, навязанную на слое доступа к данным
• Аутентификация SCIM-токеном для API провижининга (зависит от первоначально настроенного SSO)
• Лимитирование запросов по API-ключу на публичной REST и webhook-поверхности (60 запросов/минуту и 1 000 запросов/час на ключ); отдельный IP-лимитер на анонимной веб-форме контакта (5 / 15 минут)
• JWT bearer-токены для админ- и учащийских эндпоинтов на стороне браузера; долгоживущие хешированные API-ключи для публичной поверхности — полные детали в Аутентификации

Подписание webhook'ов

Исходящие webhook'и из SecureCodingHub в Ваши эндпоинты подписываются HMAC-SHA256 с использованием секрета на эндпоинт, показываемого администратору один раз при создании эндпоинта и никогда не возвращаемого снова. Заголовок подписи имеет вид t=<unix_seconds>,v1=<hex>; подписанная полезная нагрузка — это <t>.<raw_body>. Получатели должны отклонять любую доставку, чья временная метка отличается более чем на 5 минут от часов получателя для защиты от replay, и сравнивать подписи в постоянное время.

Доставка минимум один раз. Неудачные доставки (любой не-2xx ответ или сетевой сбой) повторяются с экспоненциальным backoff по расписанию 1м / 5м / 30м / 2ч / финальная попытка. После пяти неудачных попыток эндпоинт автоматически отключается, и администратор организации уведомляется через журнал аудита. Образцы кода настройки и верификации живут в API → Webhook'и.

Обработка секретов на уровне приложения

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

Сообщение об уязвимостях

Если Вы обнаружите уязвимость безопасности, свяжитесь с security@securecodinghub.com. Мы серьёзно относимся ко всем сообщениям и стремимся ответить в течение 48 часов.

Классификация данных в SecureCodingHub

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

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

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

Как шифрование организовано слоями

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

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

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

Субпроцессоры и позиция резидентности данных

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

Если в будущем мы добавим развёртывание в ЕС, изменения будут существенными, а не косметическими. Отдельный основной регион подразумевает отдельный набор субпроцессоров с операциями, резидентными в ЕС, отдельный набор destination'ов резервных копий и обновлённое дополнение к обработке данных, отражающее новый поток. Мы не будем тихо обратно портировать существующие организации в новый регион; любой переезд будет opt-in миграцией с уведомлением и определённым окном перехода. Текущий список субпроцессоров, заявление о региональной позиции и текущая сводка пентеста доступны по запросу от security@securecodinghub.com. Мы отвечаем на анкеты безопасности вендоров напрямую, а не только через общие trust-порталы, и мы не требуем, чтобы запрашивающая сторона была платящим клиентом для получения текущего списка субпроцессоров.