権限・ログ設計で押さえておきたいセキュリティ観点

企業向け業務システムでは、権限設計とログ設計がそのままセキュリティ品質に直結します。 特に BtoB 業務では、複数部署・複数拠点が利用し、機密情報を扱うケースが多いため、 「最低限の制御だけ入れておく」では不十分です。 本記事では、実務で必須となる権限とログの設計観点を体系化して整理します。

1. 権限設計は「役割ベース（RBAC）」を基本にする

個々のユーザーに細かく権限を付与する方式は、短期的には簡単でも、長期運用で必ず破綻します。 そこで多くの企業システムでは「役割ベース（RBAC：Role-Based Access Control）」を採用します。

RBAC の主なメリットは次のとおりです。

• 組織変更・部署移動があっても、役割変更だけで権限を調整できる
• 「誰が何をできるべきか」を説明しやすく、内部統制に強い
• アクセス制御の設定ミスが減る

例えば製造業の案件では、購買・品質・出荷など複数部署が入り乱れますが、 このとき 「部署ロール」＋「責任範囲ロール」 の二軸で整理すると設計が破綻しません。 製造向け参考ページとして、 製造業向けWebシステム活用アイデア を参照すると、実際の運用イメージが掴みやすくなります。

2. 管理者権限を細分化する理由

「管理者だから全部できる」は現代のシステムではリスクが高すぎます。 管理者の中にもレベル分けを行い、操作範囲を明確にします。

2-1. よく使われる管理者区分

• システム管理者（Super Admin）： ユーザー管理・設定変更・ログ閲覧が可能
• 業務管理者（Business Admin）： 自部署の操作・承認・一部設定のみ可能
• 閲覧管理者（Read-only Admin）： 閲覧だけで変更権限なし

インテンスでも BtoB 向け案件では、Super Admin の操作範囲を必要最小限に固定し、 「現場担当者が誤って設定を壊さない」構造を作ることを重視しています。

3. ログ設計は「何が残れば復元できるか」から逆算する

ログは単なる記録ではなく、トラブル時の証跡・復元材料 です。 したがって「どこまでログを残すべきか」は運用レベルに応じて設計します。

3-1. 代表的なログ項目

• ユーザーID・IPアドレス
• 操作内容（登録／更新／削除）
• 変更前データ・変更後データ（差分）
• ログイン／ログアウト時刻
• 権限変更の履歴

特に BtoB では「誰が何を削除したのか」が問題になるケースが多いため、 削除ログは必須と考えるべきです（ソフトデリートでも履歴は残すべき）。

4. ログの改ざん防止と保持年数の考え方

ログは書き換え可能な領域に置くと証跡として機能しません。 実務では次のような防衛策を組み合わせます。

• WORMストレージ（追記のみで上書き不可）
• 外部ストレージへの定期転送
• ハッシュ化によるログチェーン
• AWS S3 Glacier など長期保管向けストレージ

保持期間の目安は一般に「1〜5年」ですが、 金融・医療・公共など法的要件がある業界ではもっと長期になります。

5. 監査対応を見据えたログの構造化

監査や外部調査で問題になるのは、 「ログがあるか」ではなく「ログが読めるか」「意味が取れるか」です。 そのため、最初から人間が読める粒度のログを設計しておくことが重要です。

• イベントIDで分類し、ログが一覧で追えるようにする
• ユーザー名・役割を付帯情報として残す
• 検索しやすいフォーマット（JSON・CSV）を採用する

運用現場での調査スピードが段違いに向上し、 結果的に障害対応・トラブル解決の時間が大幅に短縮されます。

まとめ

権限・ログ設計は、業務システムのセキュリティレベルを決定づける基盤です。 RBAC による役割整理、管理者権限の分解、操作ログの構造化、 そして改ざん防止・長期保管まで含めて体系的に整理することで、 システム全体の信頼性を大きく高めることができます。