ユーザー管理

ユーザーリスト

ユーザーページには、ソートおよび検索可能なテーブルにすべての組織メンバーが表示されます。各行にはユーザーの名前、メール、チーム、ロール、最終ログインが表示されます。無効化されたユーザーは小さなDISABLEDピルでインラインフラグ付けされます — 別個のステータス列はありません。ページ上部のCSVをエクスポートボタンは、進捗合計とともに完全なユーザーリストをダウンロードします。

ユーザーの追加

組織にユーザーを追加する方法は2つあります:

シート制限

組織にはプランに基づくシート最大数があります。その上限を超えてユーザーを追加するとエラーSeat limit reached (N). Contact support to increase.で失敗します — ユーザーページ自体には今日ライブシートカウンターは表示されません。レポートページまたは公開API GET /api/public/v1/orgを使用して、現在のユーザー数に対するmaxSeatsを読み取ってください。

ユーザーの編集

ユーザー行をクリックしてユーザー詳細ページを開きます。編集ボタンは、組織管理者が次の4つのプロパティを変更できるモーダルを開きます。すべてのフィールドは必須で、編集は完全な置換として機能します — フィールドを変更しないままにするには、現在の値をそのままにしておきます。

ユーザーの削除

ユーザー詳細ページの削除アクションは、ユーザーレコード自体を削除します。削除されると、その人はサインインできなくなります。ユーザーを削除すると、maxSeats上限に対してシートが解放されます。

ユーザーの履歴データ — 練習チャレンジ結果、学習シナリオ進捗、課題完了、獲得した証明書 — は、これらのテーブルがユーザーレコードと一緒にカスケード削除されないため、データベースから消去されません。実際には、そのデータは表示されなくなります: すべてのレポート、リーダーボード、証明書検証、ユーザー詳細ページはユーザーレコードを介して結合して表示するため、ユーザー行がなくなると、行はUIが表示しないオーファンとして残ります。

削除後に同じメールを再追加すると、新しい内部IDを持つ完全に新しいユーザーが作成されます。古いオーファン行は再アタッチされません — 管理UIには「復元」パスはありません。

エビデンス保持、コンプライアンス監査、または再雇用シナリオのためにユーザーのトレーニング履歴を表示したままにしたい場合は、削除を使用しないでください。SCIMを介してユーザーをアップストリームでデプロビジョニングするか (これによりユーザーは非アクティブに設定されますが、ユーザーレコードはそのまま保持されます)、アカウントをそのままにしておきます — メールボックスがマジックコードを受信しなくなると、サインインできません。

ロール

SecureCodingHubは2つの組織レベルのロールをサポートします:

シート管理

組織にはサブスクリプションプランによって決定されるmaxSeats制限があります。今日、ユーザーページヘッダーにライブシートカウンターはありません。使用状況を監視する必要がある場合は、公開API (GET /api/public/v1/orgはmaxSeatsを返します) から読み取り、現在のユーザー数と比較してください。追加のシートが必要な場合は、上限を上げるためにアカウントマネージャーに連絡してください。

ユーザーリストインターフェース

ユーザー管理ページは次のようになります:

ユーザー追加モーダル

+ ユーザーを追加をクリックすると、次のフォームが開きます。ロールピッカーはドロップダウンの代わりに2つの並んだカードを使用します:

周到なユーザー管理が重要な理由

ほとんどの組織は、更新請求書に表示されるまでシートの拡散に気付きません。少数の契約者がプロジェクトを終え、ディレクトリに残ります。チームが再編成され、古いチームメンバーシップは決してクリーンアップされません。2人のエンジニアが会社を去りますが、オフボーディングチケットがトレーニングプラットフォームを見逃します。1年以内に、財務チームが支払っているシートの20%がログインしない人々に属し、残ったアカウントは今日実際にチームにいる人を反映しません。

シートの拡散はセキュリティの問題でもあります。すべての非アクティブなアカウントは、攻撃者がパスワードの再利用、フィッシング、またはセッションハイジャックを通じて狙うことができる認証情報です。コードレビュープラットフォームへのアクセスを付与するのと同じSSOが、ここへのアクセスを付与する可能性があり、誰も監視していないアカウントは静かに侵害するのが最も簡単です。ユーザーリストをバックログではなくライブな成果物として扱うことは、それがインシデントになる前にそのギャップを閉じます。

ユーザー-チームマッピングを四半期ごとに監査

シンプルな四半期レビューがロスターを正直に保ちます。ユーザーリストをエクスポートし、最終ログインが90日より古いユーザーをフィルタリングし、各人が残るべきかどうかをラインマネージャーに尋ねます。チーム列をHRシステムまたは組織図と照合します — チームメンバーシップが実際の役割と一致しなくなった人は再割り当ての候補です。チームが設定されていないユーザーには特に注意してください。彼らは通常、チームレベルの課題をすり抜け、誰にも気づかれずに完了率を下に歪めます。

SCIMプロビジョニングを使用している場合、この作業のほとんどは自動的に行われます。OktaまたはAzure ADのグループメンバーシップはチームマッピングに流れ、IDプロバイダーでユーザーをデプロビジョニングすると、次の同期サイクルでSecureCodingHubで非アクティブ化されます。監査は、手動の調整ではなく健全性チェックになります。

コンプライアンスエビデンスにとってデプロビジョニングが重要な理由

PCI DSS 8.1.3とISO 27001コントロールA.9.2.6はどちらも、終了したユーザーへのアクセスを迅速に取り消す必要があります。監査員はエビデンスを探します — アカウントがサインインできなくなった時を示すタイムスタンプ付きイベント、理想的にはHRのオフボーディング日に紐付けられたもの。削除ボタンはアクセスの取り消しを満たしますが、ユーザーレコードも削除します。これは、完了したトレーニングがレポートに表示されなくなることを意味します — 行はオーファンとして残りますが、UIはそれらを表示しません。監査でその履歴をエビデンスとして表示し続ける必要がある場合は、削除を使用するのではなく、SCIM経由でデプロビジョニングしてください (アカウントを非アクティブに設定しながらユーザーレコードを保持します)。監査ログはどちらのアクションも記録します。

PCI DSS 6.2.2エビデンスパックの一部としてセキュアコーディングトレーニングを実施しているチームでは、ユーザーリストは監査期間中にスコープにいた人の証明としても機能します。監査時に、CSVエクスポートボタンまたは公開API経由でスナップショットを取得し、残りのエビデンスパックと一緒に保管してください。