ACL（Access Control List）完全ガイド：種類・仕組み・設計・運用の実践ポイント

2025年12月28日 最終更新日時 : 2025年12月28日 エバープレイ編集部

ACLとは何か — 基本概念と役割

ACL（Access Control List、アクセス制御リスト）は、対象リソースに対する「誰が」「どのような操作を行えるか」を定義するためのデータ構造です。ファイルシステム、ネットワーク機器、クラウドリソース、データベースなど、多くの領域で使われます。ACLは認可（Authorization）を実装する主要手段の一つであり、認証（Authentication）と組み合わせてアクセス管理を実現します。

ACLの一般的な構造と用語

  • ACE（Access Control Entry）：ACLの構成要素。主体（ユーザーやグループ）と許可/拒否される操作（読み取り、書き込み、実行など）を記述した1行分のルール。
  • 許可（Allow）/拒否（Deny）：ACEは許可型か拒否型かに分かれる。システムによっては拒否が優先される場合がある。
  • 継承（Inheritance）：ディレクトリに設定したACLをサブオブジェクトに引き継ぐ仕組み。企業環境では継承ルールの理解が重要。
  • マスク（POSIX ACL）：グループや名前付きユーザーに対する最大許可ビットを制限するためのエントリ。
  • 監査ACL（SACLなど）：アクセスを許可/拒否するだけでなく、アクセスログ（監査）を生成するための設定。

代表的なACLの種類

  • ファイルシステムACL：POSIX ACL（UNIX/Linux系）、NTFS ACL（Windows）。POSIXはオーナー・グループ・その他＋拡張ACL、NTFSはより細かいアクセス権や監査を持つ。
  • ネットワークACL：ルータやファイアウォール、クラウドのNACL（例：AWS Network ACL）。パケットレベルでの許可/拒否を行う。ステートレスとステートフルの違いがポイント。
  • アプリケーション/オブジェクトACL：データベース、オブジェクトストレージ（例：S3 ACL）、LDAP/Active Directory上のオブジェクト権限。

ファイルシステムACLの詳細

POSIX ACL（Linuxなど）では、所有者、グループ、その他に加えて名前付きユーザー、名前付きグループ、およびmaskを使って細かな権限制御ができます。代表的なコマンドは setfacl/getfacl です。重要な注意点は mask がグループ／名前付きユーザー権限の上限を決める点で、意図せず権限を狭めたり広げたりする原因になります。

Windows NTFS ACLはDACL（Discretionary ACL：アクセス許可を定義）とSACL（System ACL：監査を定義）に分かれます。ACEは許可（Allow）、拒否（Deny）、監査（Audit）などがあり、ACEの順序（カノニカル順）が評価に影響します。一般にカノニカル順は明示的拒否 → 明示的許可 → 継承拒否 → 継承許可の順です（Microsoftの仕様に準拠）。CLIでは icacls や SetACL、GUIではプロパティから設定可能です。

ネットワークACLの特徴と注意点

ネットワークACLは端末間通信を制御するためにIPアドレスやポート番号、プロトコルを基に許可/拒否を行います。代表的な特徴は次の通りです。

  • ステートレス（例：AWS Network ACL）かステートフル（多くのファイアウォール/セキュリティグループ）かで挙動が異なる。ステートレスは戻りパケットも個別に許可が必要。
  • ルールは評価順に処理され、最初にマッチしたルールで決まる設計が多い（ただし実装に依存）。AWS NACLはルール番号の昇順で評価され、最後に暗黙の拒否がある。
  • 明示的なdenyルールを持てることが多く、これを乱用するとメンテナンス性が低下する。

ACL評価のアルゴリズム（実務で押さえるべき点）

ACLの評価は実装差があるため、設計時に対象環境の評価順序や優先ルールを理解することが必須です。一般的なチェックポイント：

  • ACEの順序（先に評価されるACEは結果に直接影響する）。
  • 拒否（Deny）の優先度（早期の拒否が許可を打ち消す）。
  • 継承ルールと明示的設定の優先度（明示的設定を優先する実装が多い）。
  • マスクやグループメンバーシップの影響（特にPOSIX ACLで混乱しやすい）。
  • ステートレスなネットワークACLでは、双方向のルールが必要である点。

ACLと他の認可モデルの比較（RBAC、ABAC、Capability）

ACLは主体ごとにリソースへアクセス許可を直接記述するため直感的ですが、大規模環境では管理が複雑になります。代替モデル：

  • RBAC（Role-Based Access Control）：ユーザーにロールを割り当て、ロールに権限を与える。大規模組織での管理に適する。
  • ABAC（Attribute-Based Access Control）：ユーザーやリソースの属性に基づいて動的にアクセスを決定する。柔軟性が高い。
  • Capability：トークン（能力）を保持した主体が操作を実行できるモデルで、ACLと設計思想が異なる。

実務ではACLとRBAC/ABACを組み合わせることが多く、例えばOSレベルはACL、アプリケーションレベルはRBACを用いるといった分業が一般的です。

実践的な設定例（抜粋）

以下は代表的な設定/確認コマンドの例（詳細は環境のドキュメント参照）。

  • Linux POSIX ACL: getfacl / setfacl コマンドで確認・設定。
    • 例: setfacl -m u:alice:rwx file.txt（aliceに読み書き実行を付与）
    • 注意: maskが存在する場合は期待通りの権限にならないことがある。
  • Windows NTFS ACL: icacls や GUIで確認。
    • 例: icacls C:\data /grant "DOMAIN\Alice":(OI)(CI)F（Aliceにフルコントロールを継承設定で付与）
    • 注意: ACEの順序や継承の挙動を確認すること。
  • AWS Network ACL: ルール番号で評価、ステートレス。
    • 例: インバウンド80番ポートを許可するルールを追加し、対応するアウトバウンドも設定する必要がある。

よくある落とし穴とトラブルシュート

  • 意図しない継承で過剰な権限を与えてしまう（特にディレクトリ構造の変更時）。
  • POSIXのmaskを見落として、名前付きユーザーの権限が制限される。
  • ネットワークACLでステートレスを理解せずに双方向通信を許可し忘れる。
  • 明示的denyを乱用して、将来の運用やトラブルシュートを困難にする。
  • ACL管理が手動だとヒューマンエラーが発生しやすく、インフラストラクチャのコード化（IaC）や自動テストが有効。

設計・運用のベストプラクティス

  • 最小権限の原則（Least Privilege）を徹底する。アクセスは必要最低限に限定する。
  • ロールやグループを活用して個別ユーザーに直接ACLを付けない設計を心掛ける。
  • 変更管理（チケット・コードレビュー）と監査ログを組み合わせる。SACLなど監査設定を有効にする。
  • 定期的な権限レビューと自動化（スキャン、テスト）を行う。ツールで未使用権限を検出する。
  • ドキュメント化：継承ルール、特例、例外の理由を明確に残す。

移行・統合時の注意点

ACL設計を他システムやクラウドへ移行する際は、モデルの違い（例：POSIXとNTFS、またはクラウドのオブジェクトACL）を正確にマッピングする必要があります。しばしば直接変換できない権限や監査仕様が存在するため、移行計画においては権限再設計（principle-based）を検討することが推奨されます。

まとめ — ACLを安全に使いこなすために

ACLは強力かつ汎用的なアクセス制御手段ですが、実装差や評価順序、継承、マスクなどの細かな挙動によって思わぬセキュリティリスクや運用負荷を招きます。設計段階でのモデル選定（ACL単独かRBAC/ABACとの併用）、最小権限の徹底、監査と自動化、定期レビューを組み合わせることで、安全で運用しやすいアクセス制御基盤を構築できます。

参考文献

カテゴリー
IT
前の記事
ストロンググリップ完全ガイド：効果・作り方・練習法とトラブル対処法New!!
2025年12月28日
次の記事
コードネーム完全ガイド：読み方・表記・応用と実践テクニックNew!!
2025年12月28日