Роли и разрешения
SecureCodingHub использует ролевое управление доступом внутри каждой организации с двумя ролями. У каждой роли есть определённый набор разрешений на админ-поверхностях и опыт учащегося.
Обзор ролей
Каждому пользователю в Вашей организации назначена одна из двух ролей. Внутренние enum-значения — org_admin и learner; админ-интерфейс показывает их как читаемые имена ниже.
| Роль | Описание |
|---|---|
| Администратор организации | Администратор уровня организации. Управляет пользователями, командами, заданиями, пользовательскими курсами, SSO, SCIM, SCORM, API-ключами, webhook'ами, журналом аудита, отчётами соответствия и настройками организации. Имеет доступ к панели администратора. |
| Учащийся | Стандартная роль пользователя для всех разработчиков. Выполняет практические задания и сценарии обучения, отслеживает личный прогресс, зарабатывает XP и управляет собственными настройками стека. |
Матрица разрешений
Следующая таблица показывает, какие разрешения доступны каждой роли:
| Разрешение | Администратор организации | Учащийся |
|---|---|---|
| Просмотр панели администратора | ✓ | ✗ |
| Управление пользователями (добавление, редактирование, удаление) | ✓ | ✗ |
| Управление командами | ✓ | ✗ |
| Создание и управление заданиями | ✓ | ✗ |
| Сборка и управление пользовательскими курсами | ✓ | ✗ |
| Настройка SSO | ✓ | ✗ |
| Настройка SCIM-провижининга | ✓ | ✗ |
| Генерация SCORM-пакетов | ✓ | ✗ |
| Управление API-ключами | ✓ | ✗ |
| Управление webhook-эндпоинтами | ✓ | ✗ |
| Просмотр журнала аудита | ✓ | ✗ |
| Просмотр панелей соответствия | ✓ | ✗ |
| Генерация отчётов соответствия / обучения | ✓ | ✗ |
| Редактирование настроек организации (таблица лидеров, порог) | ✓ | ✗ |
| Выполнение практических заданий | ✓ | ✓ |
| Выполнение сценариев обучения | ✓ | ✓ |
| Просмотр собственного прогресса и заданий | ✓ | ✓ |
| Просмотр таблицы лидеров (когда организация разрешает) | ✓ | ✓ |
Смена ролей
Администраторы организации могут повысить учащегося до Администратор организации или понизить администратора организации обратно до Учащийся в своей организации. Изменения ролей вступают в силу немедленно при следующем запросе пользователя. Каждое изменение роли записывается в журнал аудита с актором, целью и временной меткой.
Лучшие практики
Минимизируйте число Администраторов организации
Держите число Администраторов организации в 2-3 на организацию. Это ограничивает поверхность для случайной неправильной конфигурации и поддерживает чистоту аудит-следов.
Учащийся для разработчиков
Используйте роль Учащийся для всех разработчиков. Они получают полный доступ к учебному контенту, отслеживанию прогресса и настройкам стека без каких-либо административных возможностей.
Выбор ролей для Вашей организации
Дизайн ролей внутри учебной платформы кажется менее значимым, чем дизайн ролей внутри продакшен-систем, и именно поэтому он обычно делается небрежно. Учебная платформа держит данные о том, кто что знает, какие команды слабее на каких темах и какие инженеры завершили обязательное обучение соответствию. Эти данные сами по себе чувствительны — и как конкурентная информация, и как доказательство в разговорах об аудите — и ролевая модель должна это отражать.
Администратор организации vs делегирование лидам команд
Соблазн в растущих организациях — сделать каждого инженерного менеджера Администратором организации, чтобы они могли управлять своими собственными командами без подачи тикетов. Цена этого паттерна проявляется позже. Администраторы организации могут просматривать данные каждой команды, а не только своей, что означает, что менеджер может видеть, как работает команда коллеги без его ведома. Они также могут переназначать пользователей между командами, менять сроки заданий, которые они не создавали, и модифицировать конфигурацию SSO. Для большинства организаций двух-трёх Администраторов организации — правильный потолок — обычно глава инженерии или AppSec плюс один-два назначенных администратора.
Для повседневных операций на уровне команды лучший паттерн — держать лидов команд как Учащихся и дать им фильтр панели для их команды. Они получают нужную видимость без конфигурационной власти, которая им не нужна. Если лиду команды нужно создать задание для своей команды, Администратор организации может сделать это за пару минут — гораздо дешевле, чем долгосрочная цена предоставления постоянного административного доступа более широкой группе, чем необходимо.
Минимальные привилегии и аудит-логирование
Принцип минимальных привилегий применяется внутри учебной платформы так же, как и везде. Каждый дополнительный Администратор организации — это ещё одни учётные данные, чья компрометация позволяет атакующему читать Ваши учебные данные, модифицировать Вашу конфигурацию SCIM или тихо предоставить собственной внешней учётной записи админ-доступ. Практические минимальные привилегии здесь означают по умолчанию назначать новых сотрудников как Учащихся, повышать только когда операционная необходимость ясна, и оперативно понижать, когда кто-то меняет роль.
Изменения ролей и значимые административные действия записываются с временными метками и идентификацией актора по той же причине, по которой продакшен-системы логируют привилегированные действия. Когда что-то идёт не так — удалён пользователь, который не должен был быть удалён, изменено задание за дни до аудита, по ошибке удалена команда — журнал аудита является артефактом, позволяющим Вам реконструировать, что произошло. Держите это в уме при предоставлении админ-прав, так как аудит-след в конечном итоге будет прочитан кем-то, а малый состав администраторов делает журнал читаемым. Для деталей об управлении людьми внутри этих ролей см. Управление пользователями.