属性ベースアクセス制御

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リファレンス

Tenant policy

GET /api/admin/tenant-policy
Authorization: Bearer <admin_token>

optimistic locking つきで tenant policy を更新します：

PUT /api/admin/tenant-policy
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "ifMatch": "3",
  "policy": {
    "metadata": { "status": "active" },
    "profile": "human"
  }
}

管理 endpoint:

エンドポイント	メソッド	説明
/api/admin/tenant-policy	GET/PUT	tenant contract policy の取得・更新
/api/admin/tenant-policy/presets	GET	preset 一覧
/api/admin/tenant-policy/apply-preset	POST	preset 適用
/api/admin/tenant-policy/validate	GET	現在の tenant policy の検証

ポリシー評価

POST /policy/evaluate
Authorization: Bearer <policy_api_secret>
Content-Type: application/json

{
  "subject": {
    "id": "user-456",
    "roles": [{ "name": "manager", "scope": "global" }],
    "attributes": { "department": "engineering" }
  },
  "resource": {
    "type": "expenses",
    "id": "exp-123",
    "amount": 5000,
    "department": "engineering"
  },
  "action": "approve",
  "environment": {
    "time": "2024-01-15T10:30:00Z",
    "ip_address": "192.168.1.100"
  }
}

レスポンス：

{
  "allowed": true,
  "reason": "Policy matched"
}

Policy worker endpoint は service-to-service API で、internal policy API secret を要求します。

ポリシー例

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

{
  "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. 関心の分離 - ポリシー管理をアプリケーションコードから分離

参考資料

• NIST ABACガイド
• XACML 3.0