コンテンツにスキップ
Authrim

属性ベースアクセス制御

ABAC（Attribute-Based Access Control）は、サブジェクト、リソース、アクション、環境の属性を評価することで、きめ細かなアクセス制御を実現します。

概要

AuthrimのABACでは以下が可能です：

  • 任意の属性に基づくポリシー定義
  • 論理演算子を使用した複雑な条件のサポート
  • コンテキストに基づく動的な判断
  • ドメイン固有の認可ロジック実装

基本概念

属性

属性はABACポリシーの構成要素です：

カテゴリ例
サブジェクトuser_id, department, clearance_level, groups
リソースtype, owner, sensitivity, status
アクションread, write, delete, approve
環境time, ip_address, device_type, location

ポリシー構造

{
  "id": "policy-001",
  "description": "マネージャーは10,000円以下の経費を承認可能",
  "effect": "allow",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "subject.role": { "eq": "manager" } },
      { "resource.amount": { "lte": 10000 } }
    ]
  }
}

ポリシー言語

比較演算子

演算子説明例
eq等しい{ "status": { "eq": "active" } }
ne等しくない{ "type": { "ne": "admin" } }
lt未満{ "amount": { "lt": 100 } }
lte以下{ "age": { "lte": 18 } }
gt超過{ "score": { "gt": 80 } }
gte以上{ "level": { "gte": 3 } }
inリスト内{ "department": { "in": ["sales", "marketing"] } }
contains部分文字列を含む{ "email": { "contains": "@company.com" } }
startsWithで始まる{ "path": { "startsWith": "/api/" } }
endsWithで終わる{ "filename": { "endsWith": ".pdf" } }
matches正規表現一致{ "id": { "matches": "^[A-Z]{2}[0-9]+$" } }

論理演算子

// AND - すべての条件が真である必要がある
{
  "and": [
    { "subject.role": { "eq": "manager" } },
    { "resource.department": { "eq": "subject.department" } }
  ]
}


// OR - 少なくとも1つの条件が真である必要がある
{
  "or": [
    { "subject.role": { "eq": "admin" } },
    { "resource.owner": { "eq": "subject.id" } }
  ]
}


// NOT - 条件を否定する
{
  "not": { "resource.status": { "eq": "archived" } }
}

ネストした条件

{
  "and": [
    { "subject.authenticated": { "eq": true } },
    {
      "or": [
        { "subject.role": { "eq": "admin" } },
        {
          "and": [
            { "resource.owner": { "eq": "subject.id" } },
            { "resource.status": { "ne": "locked" } }
          ]
        }
      ]
    }
  ]
}

APIリファレンス

ポリシー作成

POST /api/admin/policies
Authorization: Bearer <admin_token>
Content-Type: application/json


{
  "id": "expense-approval",
  "description": "経費承認ポリシー",
  "effect": "allow",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "subject.role": { "eq": "manager" } },
      { "resource.amount": { "lte": 10000 } }
    ]
  },
  "priority": 100
}

ポリシー一覧取得

GET /api/admin/policies
Authorization: Bearer <admin_token>

ポリシー評価

POST /api/authorize
Authorization: Bearer <access_token>
Content-Type: application/json


{
  "action": "approve",
  "resource": {
    "type": "expenses",
    "id": "exp-123",
    "amount": 5000,
    "department": "engineering"
  },
  "subject": {
    "user_id": "user-456",
    "role": "manager",
    "department": "engineering"
  },
  "environment": {
    "time": "2024-01-15T10:30:00Z",
    "ip_address": "192.168.1.100"
  }
}

レスポンス：

{
  "allowed": true,
  "decision": "permit",
  "policies_evaluated": ["expense-approval"],
  "reason": "ポリシー 'expense-approval' にマッチ"
}

ポリシー例

時間ベースのアクセス制御

{
  "id": "business-hours-only",
  "description": "営業時間内のみアクセスを許可",
  "effect": "allow",
  "condition": {
    "and": [
      { "environment.hour": { "gte": 9 } },
      { "environment.hour": { "lt": 18 } },
      { "environment.weekday": { "in": [1, 2, 3, 4, 5] } }
    ]
  }
}

リソース所有者アクセス

{
  "id": "owner-access",
  "description": "所有者は自分のリソースへのフルアクセスを許可",
  "effect": "allow",
  "condition": {
    "resource.owner": { "eq": "subject.id" }
  }
}

多段階承認

{
  "id": "high-value-approval",
  "description": "高額経費はディレクター承認が必要",
  "effect": "deny",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "resource.amount": { "gt": 50000 } },
      { "subject.role": { "ne": "director" } }
    ]
  },
  "priority": 200
}

IPベースの制限

{
  "id": "internal-only",
  "description": "管理操作は内部ネットワークからのみ",
  "effect": "deny",
  "target": {
    "actions": ["admin:*"]
  },
  "condition": {
    "not": {
      "environment.ip_address": { "startsWith": "10.0." }
    }
  }
}

ポリシー評価

決定アルゴリズム

  1. 適用可能なポリシーの収集 - ターゲット（リソース + アクション）にマッチ
  2. 条件の評価 - 各ポリシーの条件をチェック
  3. 結合アルゴリズムの適用 - 最終決定を判断

結合アルゴリズム

アルゴリズム説明
Deny Overrideいずれかのポリシーが拒否すれば、結果は拒否
Permit Overrideいずれかのポリシーが許可すれば、結果は許可
First Applicable最初にマッチしたポリシーが結果を決定
Priority-based最高優先度のマッチしたポリシーが勝つ

デフォルト決定

ポリシーがマッチしない場合：拒否（セキュアバイデフォルト）

RBACとの統合

ABACはロールベースの属性を参照できます：

{
  "condition": {
    "and": [
      { "subject.roles": { "contains": "manager" } },
      { "resource.department": { "eq": "subject.department" } }
    ]
  }
}

ベストプラクティス

ポリシー設計

  1. シンプルに始める - 基本的なポリシーから始め、必要に応じて複雑さを追加
  2. 明確な命名 - ポリシーIDと説明は自己文書化されるべき
  3. ポリシーをテスト - デプロイ前に期待通り動作することを確認
  4. ポリシーのバージョン管理 - 時間経過に伴う変更を追跡

パフォーマンス

  1. ポリシー数を最小化 - ポリシーが少ないほど評価が速い
  2. 特定のターゲットを使用 - 適用可能なポリシーを絞り込む
  3. 決定をキャッシュ - 頻繁に評価される決定をキャッシュ
  4. 属性を事前計算 - 共通の属性をトークンに埋め込む

セキュリティ

  1. デフォルト拒否 - 拒否から始め、明示的に許可
  2. 決定を監査 - 認可決定をログに記録
  3. 定期的なレビュー - ポリシーを定期的に監査
  4. 関心の分離 - ポリシー管理をアプリケーションコードから分離

参考資料