これは何か
権限設計表は、システムを使う人の「役割」ごとに、どの機能・どのデータに対して、何をしてよいか（見る・登録する・変更する・承認する など）を一覧にした成果物です。
ここでの「権限」とは、システムの中で許されている操作のことです。ログインできる（本人であることを確かめる）ことと、何をしてよいか（権限）は、別の話です（08-01）。
なぜ作るか
- 仕事に必要な分だけの権限を与える（必要最小限、08-02）
- 人ごとではなく役割ごとに決めることで、異動や入退社のたびに一から考えなくてよくなる（08-03）
- 「登録する人」と「承認する人」を分けるなど、1人で不正や誤りを完結できない形にする
- 監査のときに、誰に何を許していたかを説明できる
誰が使うか・いつ作るか
- 作る人：業務の担当（どの役割に何が必要かを知っている人）と、セキュリティの担当
- 承認する人：業務の責任者と、セキュリティの責任者
- 使う人：システムに権限を設定する担当、監査の担当
- 一般的には、業務の流れと画面・機能が決まってきた設計の段階で作り、テストで確かめ、稼働後も定期的に見直します
- アステリア案件の役割の一覧、権限の中身、承認者は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
権限に関係する記載
- SYS-08 認証・ID基盤
- IF-10 認証・ID → 新基幹
- Vendor B / クラウドブリッジの担当範囲に IAM（利用者と権限の管理の仕組み）が含まれる
- SYS-10 AI開発エージェント
- P-012 石井 稔 — セキュリティ責任者
- P-013 木村 亮 — AIガバナンス責任者
- セキュリティ例外承認は、AIへ最終委任しない事項の1つ
新基幹システムを使う役割の種類、役割ごとの権限、権限を承認する人、見直しの頻度は、正本に記載がありません。未確定 上の人物が権限設計表を承認するという記載もありません。未確定
主な項目
一般的には、次の2つの表で構成します。
役割の一覧
- 役割の名前と説明（どんな仕事をする人か）
- 役割を与える条件と、与えることを承認する人
- 1人に同時に与えてはいけない役割の組み合わせ
役割 × 機能（またはデータ）の表
- 行：機能やデータ
- 列：役割
- 各マス：見る・登録・変更・削除・承認 など、許す操作
- 見られるデータの範囲（例：自分の部署の分だけ）
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 役割 × 機能の表
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、権限設計表の読み方を学ぶための例です。役割・機能・権限は、すべて教材上の架空の例で、アステリア案件の設計ではありません。
| 機能 | 案件担当 | 案件の承認者 | 経理担当 | システム管理者 | 監査担当 |
|---|---|---|---|---|---|
| 案件の登録 | 登録・変更（自部署） | 見る（自部署） | 見る | ― | 見る |
| 案件の承認 | ― | 承認（自部署） | ― | ― | 見る |
| 工数の確認 | 見る（担当案件） | 見る（自部署） | 見る | ― | 見る |
| 利用者と役割の設定 | ― | ― | ― | 登録・変更（申請に基づく） | 見る |
| 操作の記録 | ― | ― | ― | 見る | 見る |
| 組み合わせ | 理由（教材上の例） |
|---|---|
| 案件担当 と 案件の承認者（同じ部署） | 自分で登録した案件を、自分で承認できてしまう |
| システム管理者 と 業務の役割 | 自分に権限を足して、業務の操作ができてしまう |
「―」は、その操作を許さないことを表します。何も書かれていないマスを作らず、許さないことも明示します。
読み方
- 役割ごとに縦に読み、その役割の仕事に必要のない操作が入っていないか
- 機能ごとに横に読み、「承認」ができる役割が、登録する役割と分かれているか
- 「見る」の範囲（自部署だけか、全社か）が書かれているか
- システム管理者が、業務のデータを変更できるようになっていないか
- 同時に与えない組み合わせが決められているか
書き方
- 業務の流れから、仕事の種類（役割）を洗い出す。人の名前から作らない
- 機能とデータの一覧を作る
- 役割ごとに、仕事に必要な操作だけを入れる。迷ったら「与えない」から始める
- 同時に与えない組み合わせを決める
- 業務の責任者とセキュリティの責任者が確かめ、承認する
- テストで、許した操作ができ、許さない操作ができないことを確かめる
- 稼働後、定期的に見直す（使われていない権限、異動した人の権限）
何を書いてはいけないか
- 人の名前ごとの権限（役割で設計し、人には役割を割り当てる）
- 「全権限」「管理者と同じ」のような、中身の分からない書き方
- 「とりあえず全員に見せる」ような、理由のない広い権限
どこを見るか
- 登録と承認が、別の役割に分かれているか
- 見られるデータの範囲
- システム管理者の権限の範囲
- 同時に与えない組み合わせ
- 承認した人と日付、見直しの記録
赤信号
- 全員が同じ役割
- 1つの役割が、登録・承認・設定をすべてできる
- 空欄のマスがあり、許すのか許さないのかが分からない
- 開発やテストのために与えた広い権限が、本番でも残っている（08-05）
よくある失敗
- 最初に広い権限を与え、あとで絞ろうとして、絞れなくなる
- 異動・退職のときに、古い役割を外し忘れる
- 権限設計表と、実際にシステムに設定された権限が食い違う
関係するUnit・成果物・危機演習
- Unit：08-03 権限を役割単位で設計する、08-02 必要最小限の権限とは何か、08-01 ログインできれば安全なのか、08-05 開発者は本番データを自由に見てよいのか
- 成果物：SEC-003 本番特権アクセス管理表、SEC-004 監査ログ要件一覧、AI-002 AIエージェント権限表、SEC-005 セキュリティ評価報告書
- 危機演習：AIを開発に使う場面は CR11 で体験します（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
AIは、権限設計表の中の「強すぎる組み合わせ」を探す下書きに役立ちます。
「この権限設計表から、①同じ役割で登録と承認の両方ができる機能、②空欄のマス、③システム管理者が業務のデータを変更できる機能、を挙げてください。権限を変更する案は出さないでください。」
REVIEW
- AIが挙げた箇所が、表の元の内容と合っているか
- AIが見落とした組み合わせがないか（同時に与えない組み合わせと照らす）
- AIに実際の利用者の一覧を渡していないか（必要な場合は、扱いを事前に確かめる）
人間が判断すること
- どの役割に、どの操作を許すか
- 例外として広い権限を与えるか（与える期間と理由）
- 権限設計表を承認するか
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 08｜誰に何を許可するのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この表を見た人は、「この役割の人は、何ができて、何ができないのか。それは誰が決めたのか」を答えられますか？