認証と認可の判断表
一つの保護対象操作について認証と認可を分け、責任者、拒否、セッション、再認証、判断記録、テスト、未決時の停止条件を空欄の判断表にまとめます。
認証に成功しても、操作を許可できるとは限りません。認証は「誰だと確かめたか」を確認します。認可は「その主体に対象への操作を許してよいか」を判断します。明示された許可条件に合わない場合や判定に失敗した場合は、処理を実行しない設計が必要です。
想定読者は、小さなWebサービスや社内システムを初めて設計する人です。この記事では、操作を求める人やシステムを「操作主体（actor）」、操作の対象を「リソース（resource）」と呼びます。実行内容は「操作（operation）」、判断時の周辺条件は「判断条件（context）」です。
完成状態は、空欄テンプレートを使い、一つの操作に必要な判断と未確認事項を記入できた状態です。実装へ渡すかHOLDにするかを、人が判断できる状態も必要です。セッションは認証状態を継続する仕組み、再認証は認証根拠の取り直しです。責任者、拒否時の動作、判断記録、テストも同じ表で追跡します。すぐに作業を始める場合は、空欄の認可判断表へ進めます。
HOLDは、未確認事項があるため設計・実装・受入を止めるTsuzura独自の状態です。実行時の認可結果ではありません。実行時には許可または拒否を返し、判定できないときに処理を実行しない方針を採ります。外部へ返す状態や内部での分類は、システムの方針で決めます。
始める前に、操作の目的、対象外、業務責任者、受入条件を要件と受入条件で確認します。これらが未決なら、認可ルールを決める段階ではありません。本記事は設計を実装へ渡すための記録であり、障害対応手順や本番変更の承認記録ではありません。
OAuth・OpenID Connect（OIDC）の実装、トークンやコードの例、パスワードのハッシュ化、MFA製品の設定は扱いません。本人確認制度、法的助言、攻撃手順、脅威モデル全体も対象外です。NISTとOWASPの資料は設計上の参考であり、日本法上の義務として紹介するものではありません。
認証と認可は答える質問が違う
認証は識別情報の確からしさを確認し、認可は操作の可否を決めます。二つを同じ確認にまとめると、「ログインできたので全データを扱える」という誤った実装につながります。
識別情報（identity）は、システム内で人やサービスを見分けるための情報です。認証（authentication）は、その識別情報に結びついた認証器を操作主体が管理しているか確かめる手続きです。認証器には、パスワードや暗号鍵を保持する端末があります。証明書を使う方式では、対応する秘密鍵を保持する端末などが認証に関わります。NIST SP 800-63-4のAuthentication Processは、登録済みの識別情報に結びつく認証器を検証し、成功後に認証済みセッションを始めるモデルを示しています。
認可（authorization）は、特定の主体に、求められた操作やサービスを許可するか確かめる手続きです。OWASP Authorization Cheat Sheetも、認証と認可を別の手続きとして定義しています。
認証保証水準は、認証の確からしさに対する要求です。認可方針は、許可・拒否のルールと例外をまとめたものです。
| 判断 | 答える質問 | 主な入力 | 出力 |
|---|---|---|---|
| 認証 | どの識別情報を示す根拠があるか | 認証器、認証結果、確認時刻、認証保証水準 | 成功・失敗と識別情報 |
| 認可 | その主体が対象へ操作をしてよいか | 操作主体、リソース、操作、判断条件、認可方針 | 許可・拒否 |
認証結果は認可の入力の一つであり、認可結果そのものではありません。公開リソースは、認証なしでも許可する場合があります。一方、認証済みでも許可対象外の操作は拒否します。
認可判断は四つの入力から作る
認可ルールでは、操作主体とリソースを分けます。操作と判断条件も別に記録します。役割名、URL、画面上のボタンだけでは、誰にどの操作を許したか確認できません。
OWASP Authorization Cheat Sheetは、利用技術を先に固定せずに要件を整理するよう示しています。設計時には、利用者の種類とリソースを列挙します。操作と必要な属性も確認対象です。本記事では、属性や周辺条件を「判断条件」としてまとめます。この四分類は、Tsuzuraが一つの操作へ当てはめるために整理した方法です。公式規格の書式ではありません。
操作主体と識別情報の種類を分ける
操作主体は、操作を求める人またはシステムです。識別情報の種類には、人、バックエンドサービス、定期処理、外部システムなどがあります。同じ人が複数の役割を持っていても、役割名だけで許可は決まりません。どの識別情報から、どの認証結果を受け取るか確認します。
認証の根拠には、検証済みの識別子と認証時刻を記録します。認証保証水準と、発行・検証主体への参照も必要です。認証保証水準（assurance）は、認証の確からしさに対する要求を指します。本記事の判断表には、パスワードやセッションの秘密値を記入しません。アクセストークンそのものも対象外です。OWASP Logging Cheat Sheetも、これらをアプリケーションログへ通常は直接残さないよう示しています。
リソースの所有者と組織境界を確認する
リソースは、操作対象となる記録やファイルです。アカウント、設定、機能もリソースになり得ます。IDの形式が正しくても、操作主体がそのリソースを扱えるとは限りません。OWASP Authorization Cheat Sheetは、同じ種類の対象へアクセスできることと、個別対象への権限を区別しています。個々の対象や機能について、リクエストごとの確認が必要です。
リソースには、識別方法と所有者を記録します。分離単位と情報の機微度も必要です。テナントは、同じサービス内でデータや権限を分離する単位です。組織や顧客が一つのテナントに当たります。テナントを使わないシステムでは、実際に可否を変える所有関係や所属関係を使います。推測しにくいIDへ変えるだけでは認可になりません。
操作と判断条件を具体化する
操作は「管理できる」のような広い表現を避けます。読む、更新する、削除するといった単位へ分けます。同じリソースでも、読取りと削除では必要な承認や再認証が異なる場合があります。
判断条件は、認可に使う周辺情報です。認証保証水準、リソースの状態、所有者との関係などが候補です。業務承認や委任範囲を使う場合もあります。取得できない条件で結論が変わる場合は、失敗時の動作と責任者も必要です。条件を増やすだけで安全になるわけではありません。
認可はサーバー側でリクエストごとに判定する
許可と拒否は、信頼できるサーバー側でリクエストごとに決めます。入力を認可方針へ照合する場所が判定点です。拒否時に処理を止める場所を強制点と呼びます。許可ルールがない場合の既定結果は拒否です。判定処理が失敗した場合も、保護対象の処理は実行しません。これは本記事で採る、失敗時は処理を止める設計方針です。
認可方針（policy）は、四つの入力のどの組合せを許可または拒否するか定めたルールです。方針責任者は、そのルールと例外を承認します。一つのミドルウェアやアプリケーションが、判定点と強制点の両方を担う場合もあります。
OWASP Authorization Cheat Sheetは、既定拒否とリクエストごとの権限確認を示しています。また、クライアント側の確認を最終判断にしないよう求めています。ボタンを隠す処理は画面表示には使えますが、サーバーを直接呼ばれた場合の拒否にはなりません。クライアントとサーバーのデータ境界は、レンダリング方式とも照合できます。
判定の記録順は次のとおりです。
- リクエストから、検証済みの操作主体を得る。得られない場合は認証失敗として扱う。
- リソースと所有者・テナントの関係をサーバー側で解決する。
- 操作と判断条件を認可方針へ照合する。明示された許可ルールに合わなければ拒否する。
- 強制点では、許可された場合だけ処理を実行する。例外や依存先の失敗時にも実行しない。
- 秘密値を含まない判断記録を残し、許可・拒否のテストへつなぐ。
最小権限は、業務に必要な操作だけを操作主体へ許す考え方です。NIST CSF 2.0のPR.AA-05は、アクセス権限と認可を方針で定義・管理・強制・見直す成果を示しています。最小権限と職務分離も含まれます。NIST CSFは、実装製品や役割構成までは指定していません。具体的なルールは、方針責任者がシステムのリスクに応じて決めます。
人のIDとシステム用IDを分ける
NIST CSF 2.0のPR.AA-01、PR.AA-03、PR.AA-05は、人だけでなくサービスや機器の識別情報・認証情報を管理する成果を示しています。権限を方針で管理することも含まれます。特定の製品やトークン形式を勧める記述ではありません。本記事では、この成果を一つの操作へ当てはめるため、人のIDとシステム用ID（service identity）を区別して管理します。
本記事の判断表では、システム用IDの責任者、用途、呼出元を確認します。対象と許可操作も記録します。認証情報の発行・更新・失効方法と、判断記録の保存先も確認します。これはNISTの必須項目一覧ではなく、Tsuzuraが抜けを探すためにまとめた確認項目です。
別の主体に代わって処理する場合は、権限の委任も確認します。まず、委任元と委任先が必要です。許可範囲、期間、失効条件も決めます。どれかが未決なら、認可ルールを確定できません。その場合、実行時の処理は許可せず、設計・受入をHOLDとして記録します。OAuthやOIDCを採用しても、プロトコル名だけでは空欄を埋められません。採用版と提供者の公式資料が、実装判断に必要です。
セッションと再認証条件を別に決める
セッションは、認証後のやり取りを継続させる仕組みです。個々の操作の認可を省く仕組みではありません。開始と終了に加え、権限変更や再認証も一つの流れとして決めます。ログアウトや強制失効も終了条件に含まれます。
NIST SP 800-63B-4のSession Managementは、認証後にセッションを開始できると定めています。明示的なログアウトや無操作時間の超過などが終了条件です。OWASP Session Management Cheat Sheetも、期限切れとログアウトでサーバー側のセッションを無効化するよう示しています。
| セッション上の出来事 | 方針で決めること | 確認する結果 |
|---|---|---|
| 認証成功 | どの識別情報と保証水準で始めるか | 新しいセッションが正しいIDに結びつく |
| 認証・権限水準の変更 | セッションIDをどう更新し、権限をどう再評価するか | 旧セッションIDを受理せず、新しい権限を反映する |
| 無操作・全体の期限 | どのリスクと利用条件で終了するか | 期限後のリクエストが拒否される |
| 機微な操作・リスク事象 | どの認証根拠を取り直すか | 古いセッションだけでは実行できない |
| ログアウト・強制失効 | どの端末やサービスを終了するか | 対象セッションを再利用できない |
セッション時間に普遍的な値はありません。NIST SP 800-63B-4では、保証水準と利用環境により期限が変わります。端末やアプリケーションの性質も判断材料です。採用する方針に数値がある場合は、対象範囲と根拠を記録します。ほかのシステムの値を根拠なく流用する方法は採りません。
OWASP Session Management Cheat Sheetは、認証時と権限水準の変更後にセッションIDを更新し、旧IDを破棄するよう示しています。方式が異なる場合も、旧セッションの秘密値をどう失効させるかを、採用方式の公式資料と認可方針で決めます。変更後の権限は、次のリクエストで改めて評価します。OWASP Authorization Cheat Sheetも、リクエストごとの権限確認を示しています。
重要な操作やアカウント回復は、再認証の候補です。認証情報を変更した後や、不審な活動を検知した後も候補になります。OWASP Authentication Cheat SheetとOWASP Session Management Cheat Sheetは、機微な機能やリスク事象の後に再認証する考え方を示しています。どの兆候で何を求めるかはシステム固有です。本記事では、一つの位置情報や端末情報だけで不正と決めない方針を勧めます。誤判定からの回復方法と問い合わせ先も、責任者が決める項目です。
拒否時の動作・判断記録・テストを先に決める
認証・認可の失敗は、通常の分岐として設計します。利用者へ返す情報と、内部で追跡する判断記録は分けます。許可時だけでなく、拒否時や依存先の失敗時に保護対象の処理が実行されないことも確かめます。
認証失敗時にアカウントの存在や停止状態を応答で区別すると、内部状態を推測されるおそれがあります。OWASP Authentication Cheat Sheetは、ログインやパスワード回復で共通の応答を使うよう示しています。回復案内までなくすという意味ではありません。外部応答で状態を開示せず、問い合わせ対応と内部記録で原因を追えるようにします。
認可失敗時は、例外が起きても保護対象の処理を実行しない状態へ収束させます。OWASP Authorization Cheat Sheetは、認可を回避できる状態を生まないよう処理することを示しています。エラーへ内部の機微情報を出さないことも求めています。依存先の失敗を「拒否」「内部エラー」のどちらに分類するかは、認可方針とクライアント契約で決めます。リソースの存在を外部へ示すかも同様です。
OWASP Logging Cheat Sheetが挙げる記録候補は次のとおりです。
- 認証の成功・失敗
- 認可失敗とセッション失敗
- 権限変更と高リスク操作
記録からは、時刻、主体、操作、対象、結果、理由を追跡できる必要があります。本記事では、対象版と判定点も候補に加えます。認可方針の版と確認者も同じ判断記録へ残します。設計がHOLDになった理由は、実行時ログではなく判断表の変更履歴へ残します。
同じOWASP Logging Cheat Sheetは、セッション識別子やアクセストークンを通常は直接ログへ残さないよう示しています。パスワードや暗号鍵も同様です。必要に応じて削除や伏字を使い、識別子を保護します。要件に応じてハッシュ化や暗号化も検討します。個人情報や商業機密を収集する場合は、適用法と組織方針の責任者への確認が必要です。保存期間と閲覧権限も確認対象です。
テストでは、同じ対象版と認可方針の版を使います。
- 許可テスト：認証根拠、主体と対象の関係、操作、判断条件が許可ルールに合う。
- 拒否テスト：認証根拠の不足、別の主体、別の所有者・テナント、未許可操作を個別に拒否する。
- 失敗時テスト：ID、リソース、認可方針、セッションを取得できなくても処理を実行しない。
- 認証・権限変更テスト：セッションIDを更新し、旧IDを受理せず、変更後の権限を再評価する。
- 終了テスト：ログアウト、期限切れ、強制失効後に対象セッションをサーバー側で受理しない。
- 記録テスト：判断理由と対象版を追跡でき、秘密値がログやエラーへ出ない。
テストの層と実行環境はテストの種類と選び方で決められます。単体・結合テストが通っても、未記載のルールや実装欠陥がないことは証明できません。運用上の誤設定がないことも同様です。入力処理のテストとの違いは、Webの脆弱性を防ぐ設計で確認できます。
空欄の認可判断表
次の判断表は、一つの保護対象操作を設計・実装・テストへ渡すための空欄テンプレートです。NISTやOWASPの公式書式ではありません。「必須」は一つの操作で常に判断する欄です。仕組みを使わない場合は、架空の値ではなく「不使用」と理由を記録します。「該当時」は、その仕組みを使う場合だけ確認します。各節を作業用文書へ複製して使えます。
記録担当が、分からない技術項目を決める必要はありません。「未確認」と書き、質問、回答責任者、必要な根拠を第10節へ移します。認証の項目はIDの責任者、認可ルールは認可方針責任者、実装箇所と失敗時の動作は実装責任者へ確認します。記録担当は回答と対象版を結びつけます。
記入は四段階に分けられます。
- 記録担当が対象操作と対象外を集め、各責任者が自分の判断権限を確認します。判断権限が未決の状態はHOLDです。
- ID・リソース・認可方針の責任者が、認証根拠と許可・拒否ルールを確認します。記録担当は回答と未確認事項を分けます。
- 実装責任者が判定点、強制点、失敗時、セッションを対応づけます。拒否時にも処理が続く状態は、テストへの引き渡し条件を満たしません。
- 確認者がテストと判断記録の対応を見直します。未実行テストと未確認事項を残したうえで、影響の受入責任者が最終判断します。
この判断表の承認は、設計を実装やテストへ渡す判断です。本番変更の承認、バックアップ、ロールバック、監視、障害時の連絡は別に扱います。必要な場合は、サービス運用の最小構成と公開前チェックへ引き継ぎます。
1. 対象と責任
記録担当は空欄と根拠を集めます。認可方針責任者はルールと例外を決め、実装責任者は変更範囲を管理します。確認者は独立した観点で見直します。残る影響の受入は、影響を引き受ける責任者が最終判断します。
役割と人数は別です。組織方針が認める場合は、同じ人が複数の役割を担えます。その場合は兼任した役割と残る影響を記録します。独立確認が方針上必要なのに確認者を確保できない状態はHOLDです。
個人開発や正式な組織方針がない場合は、本人が担う役割と判断権限を記録します。独立確認がないことは残る影響として扱います。機微な情報や高い影響を扱い、本人だけでは影響を判断できない場合は、外部の確認者を得るまでHOLDです。
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 保護対象の操作名と目的 | 必須 | |
| 対象となる要件・判断表の版 | 必須 | |
| 対象となるコミット | 該当時 | |
| 認可方針の版 | 必須 | |
| 対象外 | 必須 | |
| 記録担当 | 必須 | |
| 認可方針責任者 | 必須 | |
| 実装責任者 | 必須 | |
| 確認者 | 必須 | |
| 影響の受入を判断する責任者 | 必須 | |
| 外部の専門家・提供者への確認窓口 | 該当時 | |
| 現在の状態：設計中／実装へ渡す／テストへ渡す／HOLDから一つを選択。変更履歴は別に残す | 必須 |
2. 操作主体・識別情報・認証根拠
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 操作主体の種類：人／サービス／定期処理／外部システム／その他 | 必須 | |
| 識別子を発行・検証する主体 | 必須 | |
| 必要な認証根拠 | 必須 | |
| 必要な認証保証水準と理由 | 必須 | |
| 認証した時刻の新しさを確かめる方法 | 必須 | |
| 認証結果から受け取る項目。秘密値は除く | 必須 | |
| 認証情報の発行・更新・失効を管理する責任者 | 必須 |
3. リソース・所有者・テナント
| 項目 | 区分 | 記入欄 |
|---|---|---|
| リソースの種類と識別方法 | 必須 | |
| リソースの所有者 | 必須 | |
| テナント、プロジェクト、グループなどの分離単位 | 該当時 | |
| 操作主体とリソースの関係 | 必須 | |
| 情報の機微度と想定される影響 | 必須 | |
| リソース不存在と権限なしを外部応答で区別するか | 必須 |
4. 操作・判断条件・認可ルール
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 操作 | 必須 | |
| 判断に使う条件 | 必須 | |
| 許可ルール | 必須 | |
| 拒否ルール | 必須 | |
| ルール不一致時の既定結果 | 必須 | |
| 例外ルールと承認者 | 該当時 | |
| ルールを見直すきっかけ | 必須 |
5. 判定点・強制点・失敗時
| 項目 | 区分 | 記入欄 |
|---|---|---|
| リクエスト入口となるエンドポイント、処理、定期実行 | 必須 | |
| リソースと所有関係を取得する場所 | 必須 | |
| 認可の判定点 | 必須 | |
| 拒否を実際に強制する場所 | 必須 | |
| リクエストごとに確認する方法 | 必須 | |
| 変更対象の部品、ファイル、関数 | 必須 | |
| クライアント側の表示制御が担う範囲 | 該当時 | |
| ID・リソース・方針・セッション取得失敗時の内部での扱い（拒否／内部エラーなど）と外部応答 | 必須 | |
| 例外時の内部での扱い（拒否／内部エラーなど）と外部応答 | 必須 | |
| 外部へ出さないアカウント・リソース・デバッグ情報 | 必須 | |
| 拒否後に残るデータ・外部で既に起きた処理と戻し方 | 必須 |
6. セッション・再認証
| 項目 | 区分 | 記入欄 |
|---|---|---|
| セッションを始める認証 | 必須 | |
| セッション全体の期限と根拠 | 必須 | |
| 無操作時の期限と根拠 | 必須 | |
| 再認証が必要になる条件 | 必須 | |
| 機微・高リスク操作に必要な追加根拠 | 該当時 | |
| 認証・権限水準変更時のセッションID更新と旧ID不受理 | 必須 | |
| 権限変更後の再評価と既存セッションの扱い | 必須 | |
| ログアウト時のサーバー側失効 | 必須 | |
| 認証情報の漏えい・アカウント停止時の強制失効範囲 | 必須 | |
| 認証を提供する側・利用する側・各サービスに別セッションがあるか | 該当時 |
7. システム用ID・委任
| 項目 | 区分 | 記入欄 |
|---|---|---|
| システム用IDを使うか：使用／不使用と理由 | 必須 | |
| システム用IDの責任者と用途 | 該当時 | |
| 認証情報の発行・保管場所への参照・更新・失効 | 該当時 | |
| 委任元と委任先 | 該当時 | |
| 委任で許すリソース・操作・判断条件 | 該当時 | |
| 委任の期間・失効・見直し条件 | 該当時 | |
| 人のアカウントや認証情報を共有していないこと | 該当時 |
8. 判断記録と秘密情報
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 記録する認証成功・失敗、認可失敗、セッション失敗、権限変更、高リスク操作 | 必須 | |
| 時刻、認可を判断した場所、主体、操作、対象、結果、理由 | 必須 | |
| 認可方針・要件・判断表・コミットの版との対応 | 必須 | |
| 保存先、閲覧責任者、保存条件 | 必須 | |
| 直接記録しないパスワード、トークン、セッション秘密値、鍵 | 必須 | |
| 伏字・ハッシュ化などが必要な識別子と目的 | 該当時 |
9. 許可・拒否・失敗時のテスト
各テストは、入力条件、期待する許可・拒否、強制点、判断記録を同じ対象版へ結びつけます。
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 許可される主体・対象・操作・判断条件と期待結果 | 必須 | |
| 別主体・別所有者・別テナント・未許可操作と期待結果 | 必須 | |
| ID・リソース・方針・セッション取得失敗時の期待結果 | 必須 | |
| 例外・期限切れ時の期待結果 | 必須 | |
| 認証・権限変更時のセッションID更新、旧ID不受理、権限再評価 | 必須 | |
| ログアウト・期限切れ・強制失効時のサーバー側不受理 | 必須 | |
| 秘密値をログ・エラーへ出さない確認 | 必須 | |
| 強制点と判断記録への参照 | 必須 | |
| 未実行テストと残る影響 | 必須 |
10. 未確認事項・HOLD
| 項目 | 区分 | 記入欄 |
|---|---|---|
| 未確認事項と結論への影響 | 必須 | |
| 確認先へ渡す質問 | 必須 | |
| 回答に必要な根拠 | 必須 | |
| 回答を確認する責任者 | 必須 | |
| HOLDにする条件と、HOLD中に実行しない操作 | 必須 | |
| 既存のセッション・認証情報・権限の扱い | 該当時 | |
| 再開条件と見直すきっかけ | 必須 | |
| セキュリティ・プライバシー・法務・業務上の相談先 | 該当時 | |
| 外部専門家・提供者への質問と回答確認者 | 該当時 | |
| 人による最終判断と日付 | 必須 |
未決なら実行を拒否し、設計をHOLDにする
許可・拒否の結論を変える未確認事項が残る場合は、実行時に処理を許可しません。設計・実装・受入はHOLDとして記録します。停止理由、影響、確認責任者、必要な根拠、再開条件がHOLDの記録項目です。
HOLDは標準の認可結果でも、日本法上の義務でもありません。Tsuzuraが本記事で使う受入条件です。組織に承認済みの厳しい方針がある場合は、そちらが優先されます。本記事の方法では、次の状態を実装・公開前に解消するか、影響を引き受ける責任者が判断する扱いです。
- 操作主体・認証根拠・リソース境界・認可ルールのどれかが未決である。
- 判定点や強制点が不明で、失敗時にも処理が続く可能性がある。
- システム用ID、セッション失効、拒否応答、秘密情報の扱いが未決である。
- 判断記録やテスト条件を追跡できず、影響の受入責任者も決まっていない。
判断に必要な別資料は、未確認事項に応じて選びます。
- システム境界と責任者が曖昧な場合：C4システム図
- 認証から認可・データアクセスまでの順序が曖昧な場合：シーケンス図
- テストの層を選べない場合：テストの種類と選び方
- 権限やセッションの失効を運用できない場合：サービス運用の最小構成
本記事では、Tsuzuraの編集上の安全境界として、AIを承認済みの利用環境だけで補助に使います。個人開発では、利用者本人が提供者の条件と扱う情報の機微度を確認します。判断できない場合は、公開情報か作業用の仮データだけを使うか、確認者を得るまでHOLDです。
パスワードやトークンはAIへ入力しません。セッションの秘密値や鍵も同様です。識別子や個人情報は、目的に必要な範囲へ減らします。可能なら仮名へ置き換えます。未公開の構成や顧客情報を扱う場合は、責任者が提供者の保存条件と学習利用を確認します。第三者提供と契約条件も確認対象です。不明な場合は、プライバシー・法務責任者へ確認するまでHOLDです。
AIへ渡す作業は、一回につき一つの操作に限ります。判定・強制箇所と対応する正負テストまでが、同じ依頼の範囲です。これはTsuzuraの編集上の安全境界です。人が変更前に対象部品と期待結果を決め、変更後に差分とテスト結果を確かめます。AIが作ったルールや例外は未承認です。責任者の決定やHOLD解除も、人の判断がなければ承認されません。
最初に、一つの操作について「誰が何を判断するか」を書き出します。不明時に止める条件も同じ判断表へ加えると、実装へ渡せる情報と未確認事項を分けられます。実装後は対象版の判断記録をそろえ、公開前チェックで人が公開可・保留・公開不可を判断します。
出典
- National Institute of Standards and Technology, NIST SP 800-63-4 Digital Identity Model（Final、2026年8月20日確認）
- National Institute of Standards and Technology, NIST SP 800-63B-4 Session Management（Final、2026年8月20日確認）
- National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0（2024年2月26日公開、2026年8月20日確認）
- OWASP Foundation, Authorization Cheat Sheet（2026年8月20日確認）
- OWASP Foundation, Authentication Cheat Sheet（2026年8月20日確認）
- OWASP Foundation, Session Management Cheat Sheet（2026年8月20日確認）
- OWASP Foundation, Logging Cheat Sheet（2026年8月20日確認）