Docs/管理者ガイド/ロールと権限

ロールと権限

SecureCodingHubは、各組織内で2つのロールを持つロールベースのアクセス制御を使用します。各ロールには、管理者画面と学習者体験にわたって定義された権限セットがあります。

ロール概要

組織内のすべてのユーザーは、2つのロールのいずれかに割り当てられます。内部列挙値はorg_adminlearnerで、管理UIでは下記の読みやすい名前として表示されます。

ロール説明
組織管理者組織レベルの管理者。ユーザー、チーム、課題、カスタムコース、SSO、SCIM、SCORM、APIキー、Webhook、監査ログ、コンプライアンスレポート、組織設定を管理。管理者ダッシュボードにアクセスできます。
学習者すべての開発者の標準ユーザーロール。練習チャレンジと学習シナリオを完了し、個人の進捗を追跡し、XPを獲得し、自身のスタック設定を管理します。

権限マトリクス

次のテーブルは、各ロールで利用可能な権限を示します:

権限組織管理者学習者
管理者ダッシュボードを表示
ユーザーを管理 (追加、編集、削除)
チームを管理
課題を作成および管理
カスタムコースを構築および管理
SSOを構成
SCIMプロビジョニングを構成
SCORMパッケージを生成
APIキーを管理
Webhookエンドポイントを管理
監査ログを表示
コンプライアンスダッシュボードを表示
コンプライアンス / トレーニングレポートを生成
組織設定を編集 (リーダーボード、しきい値)
練習チャレンジを完了
学習シナリオを完了
自身の進捗と課題を表示
リーダーボードを表示 (組織が許可した場合)

ロールの変更

組織管理者は、組織内で学習者を組織管理者に昇格させたり、組織管理者を学習者に降格させたりできます。ロールの変更はユーザーの次のリクエストで即座に有効になります。すべてのロール変更は、アクター、ターゲット、タイムスタンプとともに監査ログに書き込まれます。

ベストプラクティス

組織管理者を最小限に

組織管理者の数を組織あたり2〜3人に保ちます。これにより、偶発的な誤構成の表面積が制限され、監査トレイルがクリーンに保たれます。

開発者には学習者を

すべての開発者に学習者ロールを使用します。彼らは管理者機能なしで、トレーニングコンテンツ、進捗追跡、スタック設定への完全なアクセスを得ます。

組織のロールの選択

トレーニングプラットフォーム内のロール設計は、プロダクションシステム内のロール設計よりもリスクが低いように感じられ、それがまさに不注意に行われがちな理由です。トレーニングプラットフォームは、誰が何を知っているか、どのチームがどのトピックで最も弱いか、どのエンジニアが必須コンプライアンストレーニングを完了したかに関するデータを保持します。そのデータは、競争情報としても監査会話のエビデンスとしても、それ自体で機微であり、ロールモデルはそれを反映する必要があります。

組織管理者対チームリードへの委譲

成長中の組織での誘惑は、すべてのエンジニアリングマネージャーを組織管理者にして、チケットを提出せずに自身のチームを管理できるようにすることです。そのパターンのコストは後で現れます。組織管理者は、自身のチームだけでなくすべてのチームのデータを表示でき、つまりマネージャーはピアの知らないところでピアのチームのパフォーマンスを確認できます。彼らはまた、チーム間でユーザーを再割り当てしたり、自分が作成していない課題の期限を変更したり、SSO構成を変更したりできます。ほとんどの組織では、2〜3人の組織管理者が適切な上限です — 通常はエンジニアリングまたはAppSecの責任者と1〜2人の指定された管理者です。

日常のチームレベルの運用には、チームリードを学習者のままにし、彼らのチーム用のダッシュボードフィルターを与えるのがより良いパターンです。彼らは必要な可視性を、必要としない構成権限なしに得ます。チームリードがチーム用の課題を作成する必要がある場合、組織管理者は数分でそれを行えます — 必要以上に広いグループに常設の管理者アクセスを付与することの長期的なコストよりもはるかに安価です。

最小権限と監査ログ

最小権限の原則は、他のどこにでも当てはまるようにトレーニングプラットフォーム内にも当てはまります。すべての追加の組織管理者は、その侵害により攻撃者がトレーニングデータを読み取ったり、SCIM構成を変更したり、静かに自身の外部アカウントに管理者アクセスを付与したりできる1つ追加の認証情報です。ここでの実用的な最小権限とは、新入社員をデフォルトで学習者にし、運用上の必要性が明確な場合にのみ昇格させ、誰かがロールを変更したらすぐに降格させることを意味します。

ロールの変更と重要な管理アクションは、プロダクションシステムが特権アクションをログに記録するのと同じ理由で、タイムスタンプとアクター身元とともに記録されます。何かがうまくいかないとき — 削除されるべきでなかったユーザーが削除された、監査の数日前に課題が変更された、誤ってチームが削除された — 監査ログは何が起こったかを再構築できる成果物です。管理者権限を付与するときはそれを念頭に置いてください。監査トレイルは最終的に誰かに読まれ、小さな管理者ロスターはログを読みやすくします。これらのロール内の人々の管理の詳細については、ユーザー管理を参照してください。

次のステップ: 組織のトレーニングを開始するためにチームをセットアップし、課題を作成します。