【入門編】 ABAC(属性ベースアクセス制御)による動的なアクセス制御 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーの管理やセキュリティ対策を任されると、聞き慣れないカタカナ用語ばかりで「どこから手をつければいいんだろう……」と不安になりますよね。

今回は、これからのセキュリティの主流であり、柔軟かつ強力な守り方である 「ABAC（属性ベースアクセス制御）」 について、身近な例えを交えながら一緒に一歩ずつ学んでいきましょう！

—

1. 昔ながらの「合鍵（RBAC）」の限界

セキュリティの基本といえば、これまで「役割（ロール）」に基づいた制御、いわゆる RBAC（Role-Based Access Control） が主役でした。これは会社でたとえるなら 「役職ごとの合鍵」 のようなものです。

「マネージャーの鍵」を持っている人は、すべての部屋に入れる。
「一般社員の鍵」を持っている人は、自分のフロアだけに入れる。

これ自体は分かりやすいのですが、現代の働き方やクラウドの環境では、ちょっと物足りなくなってきました。例えば、こんなシチュエーションを想像してみてください。

> 「一般社員のA君は自分の合鍵を持っているけれど、今日の深夜2時に、会社の外にある怪しいフリーWi-Fiから会社の重要サーバーにアクセスしようとしている……」

RBACのルールだけだと、「一般社員の鍵だから通しちゃおう」とドアが開いてしまうかもしれません。これでは少し不安ですよね。

2. ABACってなに？身近な「スマートハウスのセキュリティ」で理解しよう

そこで登場するのが、今回のテーマである ABAC（Attribute-Based Access Control / 属性ベースアクセス制御） です。

ABACを分かりやすく例えるなら、最新の 「スマートハウスの自動ロックシステム」 です。
このシステムは、単に「誰の鍵か」だけでなく、さまざまな 「属性（コンテキスト＝状況）」 を同時にチェックしてドアを開けるかどうかを判断します。

誰が？（Who）： ユーザーの身元（A君）
どこから？（Where）： IPアドレスや場所（会社のオフィスから？それとも海外から？）
いつ？（When）： アクセスした時間帯（平日の日中？それとも真夜中？）
何を使って？（Device）： 会社の管理下にある安全なパソコン？それともセキュリティ対策がボロボロの個人スマホ？

これら複数の「属性」をパズルのように組み合わせて、「この条件がすべて揃っていれば通すけれど、一つでも怪しい点があればシャットアウトする！」 という動的な（ダイナミックな）制御を行うのがABACの正体です。

—

3. 実践！ABACの考え方をサーバー設定に落とし込んでみよう

「概念は分かったけれど、実際にどうやってサーバーやアプリケーションで設定するの？」と思いますよね。
ここでは、Webアプリケーションの入り口（リバースプロキシやミドルウェア）で、ABACの考え方を取り入れた簡単な制御ロジックのサンプルを見てみましょう。

今回は、Node.js（Express）を例に、「社内IPからのアクセスであること」「平日の日中（9時〜18時）であること」 という属性をチェックしてアクセスを許可するコード書いてみます。

const express = require('express');
const app = express();

// ABACのポリシー評価を行うミドルウェア（門番の役割）
function abacPolicyCheck(req, res, next) {
    // 1. ユーザーの属性を取得する（今回はIPアドレスとアクセス時間）
    const clientIp = req.ip; // 接続元のIPアドレス
    const now = new Date();
    const currentHour = now.getHours();
    const dayOfWeek = now.getDay(); // 0(日曜)〜6(土曜)

    // 2. ポリシー（許可する条件）の定義
    // 条件A: 社内ネットワークからのアクセスか？ (ここでは例として 192.168.1.xxx を社内とする)
    const isInternalNetwork = clientIp.startsWith('192.168.1.');

    // 条件B: 平日（月〜金）の 9:00 から 18:00 の間か？
    const isWeekday = (dayOfWeek >= 1 && dayOfWeek <= 5);
    const isBusinessHours = (currentHour >= 9 && currentHour < 18);

    // 3. 属性の評価（すべての条件が揃っているか？）
    // ※ 実際の現場では、これにデバイスの健全性フラグなども追加されます
    if (isInternalNetwork && isWeekday && isBusinessHours) {
        console.log('[許可] すべてのセキュリティ属性がクリアされました。');
        return next(); // 条件クリア！次の処理へ進む
    } else {
        console.log('[拒否] 属性の評価でポリシー違反が検出されました。');
        return res.status(403.4).json({
            error: 'アクセスが拒否されました：許可されていない時間帯、またはネットワークからのアクセスです。'
        });
    }
}

// 機密データを扱うエンドポイントにABACの門番を配置
app.get('/api/secret-data', abacPolicyCheck, (req, res) => {
    res.json({ message: '機密情報へようこそ！安全なアクセスが確認されました。' });
});

app.listen(3000, () => {
    console.log('ABACテストサーバーがポート3000で起動しました。');
});

コードのポイント

このように、プログラム側で「誰が・いつ・どこから」という属性をリアルタイムに評価することで、静的なパスワードだけでは防げない不正アクセスを水際で食い止めることができます。

—

4. 現場で役立つ！ABAC導入のステップと注意点

いざ実務でABACを導入する際、最初から複雑なルールを作ろうとすると、システムのメンテナンスができなくなったり、正当なユーザーまで弾いてしまったりする「アクセスの塩漬け（デッドロック）」が起きてしまいます。

現場でスムーズに導入するためのコツをいくつかご紹介します。

1. 最初は「監査モード（ログ監視）」から始める
いきなり厳しくブロックするのではなく、まずはポリシーに合致しないアクセスを検知してログに記録することから始めましょう。「誰がいつどこからアクセスしているか」のベースラインが見えてきます。
2. 属性（Attribute）の信頼性を担保する
例えば、req.ip や送信されてきたデバイスの健康状態を表すヘッダーは、悪意ある攻撃者によって偽装される可能性があります。クラウドのロードバランサー（ALBやCloudflareなど）の機能と連携し、信頼できるヘッダー情報（例: X-Forwarded-For の正しいハンドリングなど）をベースに評価することが極めて重要です。
3. ポリシーを集中管理する
アプリケーションのコードのあちこちに条件分岐を書き散らすと、セキュリティホールのもとになります。可能であれば、認可専用のエンジンやポリシーサーバー（Opaなど）を導入し、ルールを集中管理するのがプロのやり方です。

—

まとめ

今回は、属性に基づいて柔軟にアクセスを守る「ABAC」についてお話しました。

セキュリティの基本は「疑うこと」ですが、現代のインフラでは「ただ閉ざす」だけでなく、「状況を正しく見極めて、安全な人にはスムーズに、怪しい人には厳しく」という、しなやかな強さが求められます。

最初は難しく感じるかもしれませんが、身の回りの防犯の仕組みと同じように「今、どんな状態かな？」と一つずつ紐解いていけば必ず理解できます。
一歩ずつ、安全で強いシステムを作っていきましょう！応援しています！