Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
UAC 仕様設計
システムのセキュリティを確保するため、ユーザーの識別・権限管理・アクセス制御の仕組みを定義します。
🎯 概要
- 目的: システムにおけるユーザー識別、権限管理、アクセス制御の仕組みを明確に定義し、セキュアかつ適切なアクセス管理を実現する
- スコープ: ロール定義、機能別アクセス権限マトリクス、認証・認可方式、データアクセス制御、監査ログをカバーする。個別画面の詳細なUI制御は対象外
- 推奨する実施タイミング: 基本設計の中盤、機能一覧とデータモデルが確定した後に実施する
- 関連するステークホルダー: システムアーキテクト、セキュリティチーム、プロジェクトマネージャー、業務担当者
📥 重要な前提知識・インプット
- 前提知識: RBAC(ロールベースアクセス制御)の概念、認証と認可の違い、OAuth2.0/OIDC、JWT、セキュリティ脅威(CSRF、XSS、セッションハイジャックなど)の基礎
- インプット: 機能一覧、ユーザー種別と業務フロー、データモデル、セキュリティ要件、法規制要件(個人情報保護法など)
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]UAC仕様書
- 必須要素: ロール定義一覧、ロール階層構造図、機能別アクセス権限マトリクス、データアクセス制御ルール、認証・認可方式定義、パスワードポリシー、トークン管理仕様、監査ログ仕様
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| ロール定義の完全性 | すべてのユーザー種別に対応するロールが定義されているか |
| 権限マトリクスの網羅性 | すべての機能に対して各ロールの権限が明示されているか |
| 最小権限の原則 | 各ロールに業務上必要最小限の権限のみが付与されているか |
| データスコープの明確性 | 各ロールがアクセス可能なデータ範囲が明確に定義されているか |
| 認証強度の妥当性 | 機密性に応じた適切な認証方式(2FA等)が選択されているか |
| 監査ログの十分性 | セキュリティ監査に必要な操作が記録対象になっているか |
👁️🗨️ レビュー観点:
- 業務要件との整合性: 実際の業務フローとロール・権限設計が一致しているか
- セキュリティ要件の充足: 情報資産の重要度に応じた適切なアクセス制御が実現できているか
- 法規制への準拠: 個人情報保護法、業界固有の規制に準拠した設計になっているか
- 運用性の確保: 権限変更、ロール追加などの運用作業が容易に実施できるか
- パフォーマンスへの影響: 権限チェック処理がシステム性能に悪影響を与えないか
🧪成果物のサンプル
# UAC仕様
本章では、システムにおけるユーザーの権限管理とアクセス制御の仕様を定義する。
---
## ロール定義
### ロール一覧
| ロールID | ロール名 | 説明 | 対象ユーザー |
|---------|---------|------|------------|
| ROLE_ADMIN | システム管理者 | すべての機能とデータにアクセス可能 | システム運用担当者 |
| ROLE_MANAGER | 店舗管理者 | 店舗内の商品・在庫・注文管理が可能 | 店舗責任者 |
| ROLE_STAFF | スタッフ | 注文処理と在庫照会が可能 | 店舗スタッフ |
| ROLE_CUSTOMER | 一般会員 | 商品閲覧・注文・マイページ閲覧が可能 | 登録会員 |
| ROLE_GUEST | ゲスト | 商品閲覧のみ可能 | 未登録ユーザー |
### ロール階層構造
```mermaid
graph TD
A[ROLE_ADMIN システム管理者] --> B[ROLE_MANAGER 店舗管理者]
B --> C[ROLE_STAFF スタッフ]
C --> D[ROLE_CUSTOMER 一般会員]
D --> E[ROLE_GUEST ゲスト]
```
上位ロールは下位ロールの権限をすべて継承する。
---
## 機能別アクセス権限マトリクス
### 会員管理機能
| 機能 | ADMIN | MANAGER | STAFF | CUSTOMER | GUEST |
|------|-------|---------|-------|----------|-------|
| 会員一覧閲覧 | ○ | ○ | × | × | × |
| 会員詳細閲覧 | ○ | ○ | × | △ (自分のみ) | × |
| 会員情報編集 | ○ | ○ | × | △ (自分のみ) | × |
| 会員削除 | ○ | × | × | × | × |
| 会員ステータス変更 | ○ | ○ | × | × | × |
### 商品管理機能
| 機能 | ADMIN | MANAGER | STAFF | CUSTOMER | GUEST |
|------|-------|---------|-------|----------|-------|
| 商品一覧閲覧 | ○ | ○ | ○ | ○ | ○ |
| 商品詳細閲覧 | ○ | ○ | ○ | ○ | ○ |
| 商品登録 | ○ | ○ | × | × | × |
| 商品編集 | ○ | ○ | × | × | × |
| 商品削除 | ○ | ○ | × | × | × |
| 在庫照会 | ○ | ○ | ○ | × | × |
| 在庫更新 | ○ | ○ | × | × | × |
### 注文管理機能
| 機能 | ADMIN | MANAGER | STAFF | CUSTOMER | GUEST |
|------|-------|---------|-------|----------|-------|
| 注文一覧閲覧 | ○ | ○ | ○ | △ (自分のみ) | × |
| 注文詳細閲覧 | ○ | ○ | ○ | △ (自分のみ) | × |
| 注文登録 | ○ | ○ | ○ | ○ | × |
| 注文キャンセル | ○ | ○ | ○ | △ (発送前のみ) | × |
| 注文ステータス変更 | ○ | ○ | ○ | × | × |
| 決済情報閲覧 | ○ | ○ | × | △ (自分のみ) | × |
### システム管理機能
| 機能 | ADMIN | MANAGER | STAFF | CUSTOMER | GUEST |
|------|-------|---------|-------|----------|-------|
| ユーザー管理 | ○ | × | × | × | × |
| ロール管理 | ○ | × | × | × | × |
| システム設定 | ○ | × | × | × | × |
| ログ閲覧 | ○ | × | × | × | × |
| バックアップ管理 | ○ | × | × | × | × |
**凡例:**
- ○: 完全なアクセス権あり
- △: 制限付きアクセス権あり
- ×: アクセス権なし
---
## データアクセス制御
### データスコープ
| ロール | データスコープ | 説明 |
|-------|-------------|------|
| ADMIN | 全データ | すべてのデータにアクセス可能 |
| MANAGER | 店舗単位 | 自店舗のデータのみアクセス可能 |
| STAFF | 店舗単位 | 自店舗のデータのみアクセス可能(一部機能制限) |
| CUSTOMER | 個人単位 | 自分のデータのみアクセス可能 |
| GUEST | 公開データのみ | 公開設定されたデータのみ閲覧可能 |
### データアクセスフロー
```mermaid
sequenceDiagram
participant U as ユーザー
participant A as 認証サービス
participant B as 認可サービス
participant D as データベース
U->>A: ログイン要求
A->>A: 認証処理
A->>U: アクセストークン発行
U->>B: データアクセス要求 + トークン
B->>B: トークン検証
B->>B: ロール・権限チェック
alt 権限あり
B->>D: データ取得
D->>B: データ返却
B->>U: データ返却
else 権限なし
B->>U: アクセス拒否 (403 Forbidden)
end
```
---
## 認証・認可方式
### 認証方式
| 認証方式 | 対象ユーザー | 説明 |
|---------|------------|------|
| ID/パスワード認証 | 全ユーザー | メールアドレスとパスワードによる認証 |
| 二要素認証 (2FA) | ADMIN, MANAGER | SMS または認証アプリによる追加認証 |
| SSO (Single Sign-On) | STAFF, CUSTOMER | 外部IDプロバイダー連携 (Google, Facebook) |
### パスワードポリシー
| 項目 | 要件 |
|------|------|
| 最小文字数 | 8文字 |
| 文字種 | 英大文字・小文字・数字・記号を各1文字以上含む |
| 有効期限 | 90日 (ADMIN, MANAGER のみ) |
| 履歴管理 | 過去3回のパスワードは再利用不可 |
| ロックアウト | 5回連続失敗でアカウントロック (30分間) |
### トークン管理
| トークン種別 | 有効期限 | 更新方式 | 用途 |
|------------|---------|---------|------|
| アクセストークン | 1時間 | リフレッシュトークンで更新 | API認証 |
| リフレッシュトークン | 7日間 | 再ログインが必要 | アクセストークン更新 |
| セッショントークン | 24時間 | アクティビティで延長 | Web画面認証 |
---
## 権限チェックのタイミング
```mermaid
graph LR
A[リクエスト受信] --> B{認証済み?}
B -->|No| C[ログイン画面へリダイレクト]
B -->|Yes| D{ロール権限チェック}
D -->|権限なし| E[403 Forbidden]
D -->|権限あり| F{データスコープチェック}
F -->|範囲外| E
F -->|範囲内| G[処理実行]
G --> H[レスポンス返却]
```
### チェックポイント
1. **画面表示時**: 画面へのアクセス権限をチェック
2. **API呼び出し時**: API実行権限をチェック
3. **データ取得時**: データアクセス権限をチェック
4. **データ更新時**: データ更新権限をチェック
---
## 特別な権限制御
### 時限的権限付与
管理者は、特定の期間のみ有効な権限を付与できる。
| 項目 | 内容 |
|------|------|
| 付与可能なロール | ADMIN のみ |
| 対象ロール | MANAGER, STAFF |
| 最大期間 | 30日間 |
| 自動失効 | 期限到着時に自動的に権限失効 |
### IPアドレス制限
管理機能へのアクセスはIPアドレスで制限可能。
| ロール | IP制限 |
|-------|--------|
| ADMIN | 社内ネットワークからのみアクセス可能 |
| MANAGER | 制限なし(推奨: VPN経由) |
| STAFF | 制限なし |
---
## 監査ログ
### 記録対象操作
| 操作種別 | 記録内容 |
|---------|---------|
| ログイン/ログアウト | ユーザーID、IPアドレス、タイムスタンプ |
| データ参照 | ユーザーID、対象データID、タイムスタンプ |
| データ更新 | ユーザーID、対象データID、変更前後の値、タイムスタンプ |
| データ削除 | ユーザーID、削除データID、タイムスタンプ |
| 権限変更 | 実行者ID、対象ユーザーID、変更内容、タイムスタンプ |
### ログ保持期間
- **一般操作ログ**: 1年間
- **重要操作ログ** (削除、権限変更など): 3年間
- **セキュリティログ** (ログイン失敗など): 2年間
---
## エラーハンドリング
| エラー種別 | HTTPステータス | メッセージ | 対応 |
|-----------|--------------|----------|------|
| 未認証 | 401 Unauthorized | "認証が必要です" | ログイン画面へリダイレクト |
| 権限不足 | 403 Forbidden | "この操作を実行する権限がありません" | エラーメッセージ表示 |
| リソース未発見 | 404 Not Found | "指定されたリソースが見つかりません" | エラーメッセージ表示 |
| トークン期限切れ | 401 Unauthorized | "セッションが期限切れです" | 再ログイン要求 |
---
## セキュリティ要件
### 通信セキュリティ
- すべての通信はHTTPS (TLS 1.2以上) で暗号化
- APIアクセスにはBearerトークン使用
- クロスオリジンリクエストはCORS設定で制限
### データ保護
- パスワードはbcryptでハッシュ化 (cost: 12)
- 個人情報は暗号化して保存
- クレジットカード情報は保存せず、決済代行サービスのトークンのみ保持
### セッション管理
- セッションIDは推測困難なランダム値
- セッション固定攻撃対策: ログイン時にセッションIDを再生成
- CSRF対策: CSRFトークンの検証を必須化
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: ロール定義とロール階層の設計
設計対象:
システムを利用するユーザーの種別を整理し、それぞれのロールを定義する。また、ロール間の階層関係(権限の継承構造)を決定する。
具体例:
- システム管理者、部門管理者、一般ユーザー、ゲストなど、どのようなロールが必要か
- 上位ロールは下位ロールの権限を継承するか、それとも独立した権限体系とするか
- ロールの粒度をどの程度細分化するか(例: 「閲覧者」と「編集者」を分けるか)
- 複数ロールの同時保持を許可するか
設計原則:
- 業務実態との整合: 実際の組織構造や業務フローに即したロール定義とし、運用時の混乱を防ぐ
- 最小権限の原則: 各ロールには業務遂行に必要最小限の権限のみを付与し、過剰な権限付与を避ける
- 将来の拡張性: 新しいユーザー種別や業務が追加された際に、ロール体系を柔軟に拡張できる設計とする
- シンプルさの維持: 過度に複雑なロール階層は運用負荷とバグの原因となるため、必要十分な粒度に留める
- 命名の明確性: ロール名は業務担当者が直感的に理解できる名称とし、略語や専門用語の多用を避ける
文書化の推奨表現:
- ロール一覧表の作成: ロールID、ロール名、説明、対象ユーザーを一覧表で整理する
- ロール階層図の作成: ロール間の継承関係を視覚的に表現した図を作成する(Mermaidなど)
- 設計判断の記録: なぜその粒度でロールを分割したのか、検討した代替案を記録する
🏗️ プロセス2: 機能別アクセス権限マトリクスの作成
設計対象:
システムの全機能について、各ロールがどの操作(参照・作成・更新・削除など)を実行できるかを定義する。
具体例:
- 会員管理機能: 管理者は全会員の情報を編集可能、一般会員は自分の情報のみ編集可能
- 商品管理機能: 店舗管理者は商品の登録・編集が可能、スタッフは閲覧のみ可能
- 注文管理機能: 顧客は自分の注文のみ閲覧可能、管理者は全注文を閲覧可能
- データエクスポート機能: 管理者のみ実行可能
設計原則:
- 網羅性の確保: すべての機能について、すべてのロールの権限を明示し、未定義の組み合わせを残さない
- 職務分離の原則: 不正防止のため、重要な操作(承認、実行など)は異なるロールに分離する
- データオーナーシップの尊重: 作成者や所属部門など、データの所有関係に基づいた権限設計を行う
- 例外ルールの最小化: 特定の機能だけ例外的な権限体系とすると運用が複雑化するため、可能な限り統一的なルールとする
- 段階的権限の明確化: 「完全アクセス」「制限付きアクセス」「アクセス不可」など、権限のレベルを明確に定義する
文書化の推奨表現:
- 権限マトリクス表の作成: 機能(行) × ロール(列)のマトリクス表で、○・△・×などの記号で権限を表現する
- 制限条件の注記: △(制限付きアクセス)の場合は、具体的な制限内容を注記する(例: 自分のデータのみ)
- 機能のグルーピング: 関連する機能をまとめて表示し、全体構造を把握しやすくする
🏗️ プロセス3: 認証・認可方式の選定
設計対象:
ユーザー識別の方法(認証)と、権限確認の方法(認可)を決定する。また、パスワードポリシー、トークン管理、セッション管理の仕様を定義する。
具体例:
- 認証方式: ID/パスワード、二要素認証(2FA)、SSO、生体認証のいずれを採用するか
- 認可方式: JWT、セッションベース、OAuth2.0/OIDCのいずれを採用するか
- パスワードポリシー: 文字数、複雑性、有効期限、履歴管理、ロックアウトルール
- トークン管理: アクセストークンとリフレッシュトークンの有効期限、更新方式
設計原則:
- セキュリティ要件との整合: 扱う情報の機密性に応じた適切な認証強度を選択する
- ユーザビリティとのバランス: セキュリティを重視しつつも、ユーザーの利便性を損なわない設計とする
- 業界標準の採用: OAuth2.0、OIDC、JWTなど、実績のある標準的な技術を優先的に採用する
- 多層防御の実現: 認証だけでなく、通信暗号化、CSRF対策、XSS対策など、多層的なセキュリティ対策を講じる
- 運用性の考慮: パスワードリセット、アカウントロック解除など、運用フローを現実的に設計する
文書化の推奨表現:
- 認証方式一覧の作成: 各ユーザー種別に対してどの認証方式を適用するかを表形式で整理する
- パスワードポリシー表の作成: ポリシー項目(文字数、複雑性など)と要件を一覧表で明記する
- トークン管理仕様の明記: 各トークン種別の有効期限、更新方式、用途を表形式で整理する
- 認証・認可フロー図の作成: シーケンス図で、ログインから権限チェックまでの処理の流れを視覚化する
🏗️ プロセス4: データアクセス制御とデータスコープの定義
設計対象:
各ロールがアクセス可能なデータの範囲(データスコープ)を定義し、データレベルでのアクセス制御ルールを決定する。
具体例:
- 全社データにアクセス可能(管理者)、自部門のデータのみアクセス可能(部門管理者)、自分のデータのみアクセス可能(一般ユーザー)
- 公開/非公開フラグに基づくアクセス制御
- 組織階層に基づくアクセス制御(上位組織は下位組織のデータにアクセス可能)
設計原則:
- データオーナーシップの明確化: 各データに対する所有者・管理者を明確にし、それに基づいた制御を行う
- 組織構造との整合: 組織の階層構造や部門配置と整合したデータスコープを設計する
- パフォーマンスへの配慮: データスコープによるフィルタリングがSQL性能に悪影響を与えないよう設計する
- 動的な権限変更への対応: 組織変更や異動に伴うデータスコープの変更が容易に反映できる仕組みとする
文書化の推奨表現:
- データスコープ一覧表の作成: ロールごとにアクセス可能なデータ範囲を表形式で整理する
- アクセス制御ロジックの明記: SQLのWHERE句相当のフィルタリング条件を疑似コードで記載する
- データアクセスフロー図の作成: リクエストからデータ取得までの権限チェックの流れをシーケンス図で表現する
🏗️ プロセス5: 監査ログ仕様の定義
設計対象:
セキュリティ監査や不正検知のために記録すべき操作と、ログの保持期間、ログフォーマットを定義する。
具体例:
- 記録対象操作: ログイン/ログアウト、データ参照、データ更新、データ削除、権限変更、設定変更
- 記録内容: ユーザーID、操作内容、対象データID、IPアドレス、タイムスタンプ、変更前後の値
- 保持期間: 一般操作ログ1年、重要操作ログ3年、セキュリティログ2年
設計原則:
- 法規制要件への準拠: 個人情報保護法や業界規制で要求される監査ログ要件を満たす
- 監査可能性の確保: 後から「誰が・いつ・何をしたか」を追跡できるよう、十分な情報を記録する
- パフォーマンスへの配慮: ログ記録処理がトランザクション性能に悪影響を与えないよう、非同期記録などを検討する
- 改ざん防止: ログ自体が改ざんされないよう、書き込み専用ストレージやハッシュ値検証などの対策を講じる
文書化の推奨表現:
- 記録対象操作一覧の作成: 操作種別ごとに記録内容を表形式で整理する
- ログフォーマットの定義: JSON形式などでログの構造を明示する
- 保持期間一覧の作成: ログ種別ごとの保持期間を表形式で整理する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『体系的に学ぶ 安全なWebアプリケーションの作り方』、OWASP Top 10、『OAuth 2.0 徹底入門』
- 関連する他のガイド: セキュリティ設計ガイド、API設計ガイド、データベース設計ガイド、個人情報保護対応ガイド
- ツール・テンプレート: draw.io、Mermaid(シーケンス図)、権限マトリクステンプレート
テンプレートサイト: 📄テンプレート集