認証
SecureCodingHubは複数の認証方法をサポートします。ブラウザセッションはJWT bearerトークンを使用し、公開APIはスコープベースの認可とキーごとのレート制限を伴う長期APIキーを使用します。
認証方法
組織に最も適した認証方法を選択してください:
Magic Code (Email OTP)
メールで送信される6桁のコードによるパスワードレスログイン。すべてのユーザーのデフォルト方法。コードは10分後に期限切れになります。管理または記憶するパスワードはありません。
OIDC (OpenID Connect)
Azure AD、Okta、または互換プロバイダー経由のエンタープライズSSO。PKCEを使用した認可コードフロー。組織に推奨。
SAML 2.0
エンタープライズ環境向けのフェデレーションベースSSO。SP起動ログインフロー。
Magic Codeフロー
デフォルトのパスワードレス認証フローは次のように機能します:
ユーザーがメールアドレスを入力
サーバーが6桁のOTPをメールに送信
ユーザーがコードを入力
サーバーがコードを検証してJWTを発行
セッション管理のためにJWTがブラウザに保存
SSOフロー
組織でSSOが構成されている場合、認証フローは変わります:
ユーザーが組織のSSOエントリポイントを開く (リンクには組織スラッグが含まれます。現在自動メール → ドメイン検出はありません)
ブラウザが構成されたIDプロバイダーにリダイレクト
ユーザーが企業認証情報で認証
IdPがSecureCodingHubコールバックに認可コード (OIDC) またはSAMLアサーションを返す
サーバーがレスポンスを検証し、初回サインインでユーザーをJITプロビジョニングし、JWTを発行
ユーザーがログイン
JWTトークン
すべてのブラウザ向けの認証済みセッションは、magic codeまたはSSOステップが成功した後にバックエンドが発行するJSON Web Tokensを使用して管理されます。
| プロパティ | 値 |
|---|---|
| アルゴリズム | HS256 |
| ライフタイム | 発行から30日間。アプリ内更新フローはありません。トークンが期限切れになると、ユーザーはmagic codeまたはSSO経由で再認証します。 |
| クレーム | ユーザーID、組織ID、ロール、名前、メール、有効期限。 |
| 送信 | すべての内部API呼び出しのAuthorization: Bearer …ヘッダー。 |
| ストレージ | sch-tokenキーの下のlocalStorageにクライアント側に保存。今日HttpOnly Cookieオプションはありません。 |
APIキーBearer (公開API)
/api/public/v1/*下の公開RESTおよびWebhookサーフェスは、JWTの代わりに長期APIキーを使用します。キーは組織 → APIキー下の管理コンソールから作成され、標準のbearerヘッダーとしてすべてのリクエストで送信されます:
Authorization: Bearer scs_live_…| プロパティ | 値 |
|---|---|
| 形式 | scs_live_ + 32ランダムbase62文字。合計41文字。 |
| ストレージ | SHA-256ハッシュ、プレフィックス、最後の4文字のみがサーバーに保持されます。完全なトークンは作成時に一度表示され、再度取得できません。 |
| スコープ | 16のきめ細かいスコープ (例: users:read、assignments:write、sarif:ingest)。必要なスコープなしのリクエストは403 insufficient_scopeを返します。 |
| ライフタイム | デフォルトで無期限。作成時にオプションの有効期限日を設定できます。キーはいつでも取り消せます。取り消しは即座に有効になります。 |
| 最終使用追跡 | 各成功した呼び出しは、監査とローテーションの衛生のためにキーのlastUsedAtフィールドを更新します。 |
完全なリファレンスはAPI → 認証とスコープにあります。
レート制限
すべての公開APIキーは、暴走するスクリプトからプラットフォームを保護し、1つのテナントが別のテナントを飢餓させるのを防ぐ2つのスライディングウィンドウで制限されます:
| ウィンドウ | 制限 | レスポンスヘッダー |
|---|---|---|
| 1分あたり | 60リクエスト | Retry-After, X-RateLimit-Window: per_minute, X-RateLimit-Limit: 60 |
| 1時間あたり | 1,000リクエスト | Retry-After, X-RateLimit-Window: per_hour, X-RateLimit-Limit: 1000 |
いずれかのウィンドウを超えるリクエストは、秒単位のRetry-Afterヘッダー付きで429 rate_limitedを受信します。別個のIPベースリミッター (5リクエスト / 15分) は、匿名のWeb連絡フォームをカバーします。JWT保護された管理APIに対する内部ブラウザセッショントラフィックは今日レート制限されません。
詳細な再試行ガイダンスとサンプル指数バックオフクライアントはAPI → レート制限にあります。
監査ロギング
すべての変更アクション — ブラウザ内の管理ユーザーから発生したものでも公開APIキーから発生したものでも — は組織ごとの監査ログテーブルに書き込まれます。読み取り専用アクション (リスト、取得、ダッシュボードクエリ) は監査されません。焦点は下流に影響を与える変更にあります。
| フィールド | 意味 |
|---|---|
action | 何が起こったかのドット付き識別子 (例: user.updated、assignment.created、apikey.revoked、sarif.ingested)。 |
actorEmail / actorRole | アクターのメールとロール。管理UI変更は人間のメールとorg_adminを運びます。APIキー変更はapikey:<api-key-uuid>とロールapi_keyを運びます。 |
targetType, targetId, targetLabel | 変更されたリソース。ラベルは監査ログUIで使用される短い人間可読な説明です。 |
metadata | 何が変更されたかを正確に記述するJSON文字列化されたコンテキスト (例: APIキーの新しいスコープ、課題の前後の期限)。 |
ipAddress | 変更を引き起こしたリクエストのソースIP。 |
createdAt | UTCタイムスタンプ。 |
完全な監査ストリームは、管理UI (組織 → 監査ログ) からまたはGET /api/public/v1/audit-log経由でプログラム的にクエリできます。両方の画面は、アクション、アクター、日付範囲によるフィルタリングをサポートし、管理UIはエビデンスパック用のCSVエクスポートを公開します。
セッションセキュリティ
- トークンはすべてのAPIリクエストで検証されます
- 無効または期限切れのトークンは拒否されます
- SSOセッションはIdPセッションポリシーを尊重します
- Magic codeはシングルユースで時間制限されます
SecureCodingHubが行った認証設計の選択と理由
SecureCodingHubのデフォルト認証パスはパスワードレスです。私たちはその決定を意図的に行いました。お客様のトレーニングデータで見られる認証情報侵害の大部分は、依然としてパスワードの再利用、弱いパスワードの選択、静的シークレットのフィッシングに起因します。プライマリログインフローからパスワードを削除することで、ポリシーが完全に緩和できない一連の失敗モードを排除します。従来のパスワードフォールバックを必要とする組織のために、現在のNISTガイダンスと一致する最小限を強制します: 複雑性ルールセットではなく長さの下限、既知の侵害されたパスワードコーパスに対するスクリーニング、侵害の証拠がない場合の強制ローテーションなし。
メールベースの回復は、SSOバックされたアカウントでも意図的に保持されます。IDプロバイダーが到達不能になったとき、または契約者の企業ディレクトリエントリが契約途中で削除されたとき、検証された所有者のためにアカウントへの確定的で監査可能なパスがまだ必要です。回復チャネルはレート制限され、シングルユースで、標準ログインイベントストリームとは別にログに記録されるため、セキュリティチームは通常のログインノイズに紛れることなく異常な回復活動を検出できます。
共有アカウントは、完全にブロックされるのではなく製品レベルで推奨されません。使用パターンが単一のシートが複数の人間で共有されていることを示唆する場合、管理コンソールに警告を表示します。なぜなら、共有シートは個人の説明責任を壊し、進捗レポートを歪め、将来のインシデント調査を複雑にするからです。ダッシュボードへのクロスチーム アクセスが必要な組織は、認証情報を再利用するのではなく、データセキュリティに記載されているロール割り当てとSCIMプロビジョニングされた学習者ロールを使用する必要があります。
認証をコンプライアンスにマッピング
SecureCodingHubはSOC 2 Type IIに準備中で、まだ監査を完了していないため、認証は主張しません。ただし、セキュリティチームがその監査のためにベンダーを評価するときに期待するのと同じコントロールファミリーに対して認証サブシステムを設計します。論理アクセスに関するSOC 2 CC6.1の期待 — 各ユーザーの一意の識別、機微なアクションのための多要素または同等のステップアップ、終了時の取り消し — は、ユーザーごとのアカウント、第2要素としてのmagic codeまたはIdP発行の認証情報、SCIM駆動のデプロビジョニングを通じて対処されます。
アクセス制御ポリシー、ユーザー登録、特権アクセスをカバーするISO 27001 Annex A.9コントロールは、文書化されたロール定義、要求された場合の検証済みドメインに制限された組織スコープの登録、各テナント内の明示的なorg_admin / learnerロール分割を通じて対処されます。PCI DSS Section 8の対象となる組織にとって、関連するコントロールは、カード会員データを保存しないことと、プラットフォームに対してカード会員を認証しないことです。SecureCodingHubはトレーニング環境であり、支払い環境ではないため、PCIが適用される表面は意図的に狭くなっています。
上記のいずれも、独自の評価の代替として読まれるべきではありません。サブプロセッサーリスト、データフロー図、現在の監査体制を含むエビデンスパッケージは、リクエストに応じてsecurity@securecodinghub.comから入手可能です。
SSOが有効化されたときに変わるもの
SSOを有効化することは、1つのログイン画面を別のものに置き換えるだけではありません — それはロールアウト前にセキュリティチームが理解すべきいくつかのランタイム動作を変更します。組織がIDプロバイダーに接続されると、メールが検証されたドメインと一致するユーザーには、ローカルmagic codeパスはもはや提供されません。代わりにIdPにリダイレクトされます。これは正しいデフォルトですが、IdP停止中の回復が完全にIT チームに移行し、SecureCodingHubサポートではなくなることを意味します。大規模なユーザーベースでSSOをオンにする前に、そのエスカレーションパスを内部で文書化することをお勧めします。
ロックアウトの動作もシフトします: SSOが有効になると、ローカルmagic codeパスでのレート制限された失敗試行は同じユーザーに適用されなくなります。なぜなら、すべての認証情報の検証がIdPで行われるからです。その後、ロックアウトポリシーはSecureCodingHubのデフォルトではなくIdP構成によって管理されます。サインイン後にユーザーが実行する変更によって書き込まれる監査ログエントリは、引き続きユーザーのメールとorg_admin / learnerロールを運びます。プラットフォームは現在、IdP側の認証方法 (例えば、IdPでMFAが満たされたかどうか) を監査行に保存しないため、そのレベルの詳細については、中央IDプロバイダー独自のログストリームに対して相関する必要があります。