この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第47回です。
第5章では、ネットワークを外部・内部の脅威から守るための セキュリティ設計を学びます。 今回は、利用者や管理者を確認し、 「誰が・何を・どこまで実行できるか」を制御するAAA を扱います。
AAAとは？認証・認可・アカウンティングを ネットワーク設計の視点で解説
「ログインできる人なら何でも操作してよい」 というネットワーク管理では、安全な運用はできません。 AAAでは、利用者や管理者の本人確認だけでなく、 実行できる操作を制限し、 いつ・誰が・何を行ったのかを記録します。 RADIUS・TACACS+・802.1Xとの関係も含めて、 実務で使える形で理解しましょう。
セキュリティ設計では、 ファイアウォールで「どのIPアドレスから通信できるか」を 制御するだけでは不十分です。
実際の運用では、 「その利用者は本当に本人か」 「ログイン後に何を許可するか」 「実際に何をしたか」 まで管理する必要があります。
この3つを整理する考え方が AAA（Authentication, Authorization, Accounting） です。
この記事を読み終えるとできること
- AAAの3要素を区別して説明できる
- AuthenticationとAuthorizationの違いを説明できる
- Accountingが必要な理由を説明できる
- RADIUSとTACACS+の用途を整理できる
- 802.1XとAAAの関係を説明できる
- AAAサーバ障害時の動作を設計できる
- 最小権限と管理者アクセス制御を設計できる
- AAA要件を顧客へ説明できる
AAAとは何か
AAAとは、利用者や管理者について 「本人かを確認する」 「許可する操作を決める」 「実行した内容を記録する」 という3つのアクセス制御を組み合わせる考え方です。
AAAは、次の3つの英単語の頭文字です。
認証
利用者や管理者が 「誰なのか」 を確認します。
あなたは誰ですか？認可
認証された人に 「何を許可するか」 を決めます。
何をしてよいですか？アカウンティング
利用者や管理者が 「何をしたか」 を記録します。
実際に何をしましたか？AAAは「ログイン認証」だけではありません。
本人確認を行った後、 利用できる権限を制御し、 実際の利用状況を記録するところまで含めて考えます。
Authentication・Authorization・Accountingの違い
Authentication：認証
Authenticationは、 ネットワークへアクセスしようとしている人や端末が 本当に許可された主体なのかを確認する処理です。
代表的な認証情報には、次のものがあります。
- ユーザー名とパスワード
- ワンタイムパスワード
- クライアント証明書
- ICカード
- 端末証明書
- 多要素認証
たとえばネットワーク機器へSSH接続するときに、 入力されたユーザー名とパスワードを AAAサーバへ問い合わせる処理が認証です。
Authenticationで分かるのは、 基本的に「誰であるか」です。
認証に成功したからといって、 すべての操作を許可する必要はありません。
Authorization：認可
Authorizationでは、 認証された利用者に対して 何を許可するのかを判断します。
たとえば、ネットワーク管理者を次のように分けられます。
| 利用者 | 許可する操作例 |
|---|---|
| 監視担当 | showコマンドなど参照操作のみ |
| 運用担当 | 定められた範囲の設定変更 |
| 構築担当 | 対象機器の設定変更 |
| 管理責任者 | 高権限操作を含む管理 |
全員が同じ管理者IDを使用すると、 認証はできても 「誰にどの権限を与えるか」を細かく制御できません。
セキュリティ設計では、 必要な人へ必要な権限だけを与える 最小権限の原則 が重要です。
Accounting：アカウンティング
Accountingは、 認証・認可された利用者が 実際にどのような操作を行ったのかを記録する考え方です。
たとえば次の情報を記録します。
- 誰がログインしたか
- 何時にログインしたか
- どの機器へ接続したか
- どの接続元からアクセスしたか
- どのコマンドを実行したか
- セッションがいつ終了したか
ここでいうAccountingは、 必ずしも「料金計算」という意味ではありません。
AAAでは、利用状況や操作履歴を 追跡・監査できるように記録する という意味で使われます。
なぜAAAが必要なのか
アカウントを集中管理できる
機器ごとにローカルアカウントを作成するのではなく、 AAAサーバ側で利用者を集中管理できます。
退職・異動へ対応しやすい
利用者の権限変更や削除を 集中管理できるため、 多数のネットワーク機器へ個別対応する負担を減らせます。
最小権限を実現できる
監視担当、運用担当、管理者など、 役割に応じて権限を分けられます。
操作履歴を追跡できる
障害や設定変更が発生した場合に、 誰がいつ何を行ったのか確認できます。
不正アクセス対策になる
未許可利用者や未許可端末を ネットワークへ接続させない仕組みに利用できます。
監査へ対応しやすい
誰にどの権限があり、 どのような操作を行ったかを残すことで、 セキュリティ監査へ対応しやすくなります。
設計では「認証方式」だけを決めないことが重要です。
誰を認証するのか、認証後に何を許可するのか、 どの履歴を何日・何年保存するのかまで セットで検討します。
AAAの基本構成
ネットワーク機器の管理者認証を例にすると、 AAAは次のような構成になります。
ネットワーク機器管理におけるAAAの基本構成
基本的な処理の流れ
- 管理者がネットワーク機器へ接続する SSHなどを使用してルーターやスイッチへ接続します。
- ネットワーク機器が認証情報を受け取る ユーザー名や認証情報を取得します。
- AAAサーバへ認証を問い合わせる ネットワーク機器がRADIUSやTACACS+などを使用して AAAサーバへ問い合わせます。
- 認証結果を受け取る AAAサーバは利用者情報を確認し、 許可または拒否を返します。
- 権限を適用する 認証されたユーザーの役割やポリシーに応じて、 実行できる操作を決定します。
- 利用状況を記録する ログイン、ログアウト、コマンド実行など、 必要な情報をAccountingとして記録します。
AAAが使われる3つの代表例
1．ネットワーク機器の管理者アクセス
ルーター、スイッチ、ファイアウォールなどへ SSHや管理GUIでログインする管理者を制御します。
- 管理者が誰かを認証する
- 管理者ごとに権限を変更する
- 実行コマンドを記録する
- 退職者・異動者の権限を一元管理する
この用途では、 細かな管理者権限制御やコマンド単位の制御を目的として TACACS+が利用されるケースがあります。
2．リモートアクセスVPN
社外からVPN接続する利用者を認証し、 接続後に利用できるネットワークを制御します。
リモートアクセスVPNとAAA
認証結果だけでなく、 ユーザーグループなどに応じて 接続先やポリシーを変える設計も考えられます。
リモートアクセスVPN自体の設計は、 「46. リモートアクセスVPN設計」 で解説しています。
3．有線LAN・無線LANの端末認証
オフィスのLANへ接続された利用者や端末を確認してから、 ネットワークアクセスを許可する用途です。
代表的なのが IEEE 802.1X を利用したネットワークアクセス制御です。
RADIUSとは
RADIUSは、 ネットワークアクセスの認証・認可情報や Accounting情報を AAAサーバとの間でやり取りするために 広く利用されているプロトコルです。
主に次のような用途で使われます。
- 有線LANの802.1X認証
- 無線LANの802.1X認証
- リモートアクセスVPN
- ネットワークアクセス制御
- 一部のネットワーク機器管理
代表的なポート番号
| 用途 | 代表的なポート | トランスポート |
|---|---|---|
| Authentication / Authorization | 1812 | UDP |
| Accounting | 1813 | UDP |
ポート番号は製品や既存環境によって 1645・1646などが利用される場合もあります。
設計時には、 実際に使用する製品・設定・既存環境を確認 してください。
RADIUSで認証後のポリシーを返す
RADIUSでは、 認証結果だけでなく属性情報を使用して 利用者へ適用するポリシーを決定できます。
環境によっては、たとえば次のような制御に利用できます。
- 所属グループに応じたVLAN割り当て
- アクセス制御ポリシーの適用
- セッション時間の指定
- VPN接続後の権限制御
RADIUSを採用するだけでは、 アクセス制御設計は完成しません。
「認証成功後にどのポリシーを適用するのか」 まで設計することが重要です。
TACACS+とは
TACACS+は、 ネットワーク機器への管理アクセスなどで利用される AAAプロトコルです。
特に、 認証・認可・Accountingを分けて扱い、 管理者ごとの権限制御を細かく行いたい場合に 利用されます。
管理者アクセスで考える
たとえば運用チームに次の3人がいるとします。
| 利用者 | 役割 | 許可する内容 |
|---|---|---|
| User-A | 監視担当 | 状態確認のみ |
| User-B | 運用担当 | 定型的な変更作業 |
| User-C | 管理責任者 | 高度な設定変更 |
全員に同じ管理者アカウントを渡すのではなく、 利用者ごとに認証し、 役割に応じて実行可能な操作を制御します。
TACACS+の通信
TACACS+では一般的に TCPポート49 が使用されます。
また、TACACS+では AAAクライアントとサーバ間の プロトコルペイロードを保護する仕組みがあります。
「RADIUSよりTACACS+の方が常に優れている」 という意味ではありません。
重要なのは、 何を認証・認可したいのか に応じて方式を選ぶことです。
RADIUSとTACACS+の使い分け
RADIUS
代表用途
- 802.1X
- 有線・無線LAN認証
- VPN利用者認証
- ネットワークアクセス制御
TACACS+
代表用途
- ネットワーク機器管理
- 管理者認証
- 管理者権限制御
- 操作記録
| 比較項目 | RADIUS | TACACS+ |
|---|---|---|
| 代表的用途 | 利用者・端末のネットワークアクセス | ネットワーク機器の管理者アクセス |
| トランスポート | 一般的にUDP | TCP |
| 代表ポート | 1812 / 1813 | 49 |
| AAAの扱い | 認証と認可が密接に関連 | 認証・認可・Accountingを分離して扱いやすい |
| 管理コマンド制御 | 製品・方式による | 細かな管理者制御に向く |
| 802.1X | 広く利用される | 通常は利用しない |
実務では、 「端末・利用者のネットワーク接続はRADIUS」 「ネットワーク機器の管理者アクセスはTACACS+」 という役割分担を検討することがあります。
ただし実際に利用可能な方式は、 AAAサーバ、ネットワーク機器、 VPN装置などの対応状況を確認して決定します。
802.1XとAAAの関係
IEEE 802.1Xは、 LANポートや無線LANへの接続時に 利用者・端末を認証してから ネットワークアクセスを許可するために利用されます。
802.1Xの3つの登場人物
Supplicant
認証を受ける側です。 PCや端末上の802.1Xクライアントなどが該当します。
Authenticator
端末から認証情報を受け取り、 認証サーバとの間を仲介します。 スイッチや無線LAN機器などが該当します。
Authentication Server
実際に認証を判定するサーバです。 RADIUSサーバなどが利用されます。
Authorization Policy
認証結果や利用者・端末属性に基づき、 接続後に適用するポリシーを決定します。
802.1X認証の基本イメージ
認証後のアクセス制御まで考える
802.1Xを導入する目的は、 単にユーザー名とパスワードを確認することではありません。
認証結果に応じて、 たとえば次のようなネットワークへ分けることを検討します。
- 社員端末用ネットワーク
- 管理端末用ネットワーク
- ゲスト用ネットワーク
- IoT端末用ネットワーク
- 認証失敗端末用の制限ネットワーク
これは次の記事 「48. ネットワークセグメンテーション」 にもつながる重要な考え方です。
Accountingでは何を記録するのか
AAAを設計するとき、 AuthenticationとAuthorizationだけを考えて Accountingを省略してしまうケースがあります。
しかし、 障害調査・監査・不正操作調査では、 「誰が何をしたのか」を追跡できることが重要です。
ネットワーク機器管理で記録したい情報
- ユーザー名
- ログイン日時
- ログアウト日時
- 接続先機器
- 接続元IPアドレス
- 使用したアクセス方式
- 実行コマンド
- セッション時間
- 認証成功・失敗
VPN利用者で記録したい情報
- VPN接続ユーザー
- 接続開始日時
- 切断日時
- 接続元情報
- 割り当てられたアドレス
- セッション時間
Accountingを設計するときは、 「ログを取るか」ではなく 「何を、どこへ、どのくらい保存するか」 を決めます。
ログ全体の設計については、 「20. ログ設計」 もあわせて確認してください。
AAA設計で決める項目
AAA設計では、 「RADIUSを使う」「TACACS+を使う」 と決めるだけでは不十分です。
認証対象
- 一般利用者
- 管理者
- 社員PC
- BYOD
- IoT機器
- VPN利用者
認証方式
- パスワード
- 証明書
- 多要素認証
- 802.1X
- 端末情報
認可ポリシー
- 利用可能サービス
- 管理者権限
- 許可コマンド
- 所属VLAN
- ACL・アクセス制御
Accounting
- 記録対象
- 保存先
- 保存期間
- 検索方法
- 監査方法
可用性
- AAAサーバ台数
- 冗長方式
- 障害検知
- タイムアウト
- 障害時動作
通信・セキュリティ
- 通信経路
- Firewall許可通信
- 送信元IF
- 共有秘密情報
- 時刻同期
要件から設計へ変換する
| 要件 | 設計へ落とす内容 |
|---|---|
| 退職した管理者がネットワーク機器へ ログインできないこと | 個人アカウントをAAAサーバで集中管理し、 機器ごとの共有管理者IDを通常利用しない |
| 監視担当者は設定変更できないこと | 利用者グループに応じて 参照権限と変更権限を分離する |
| 管理操作を追跡できること | Accountingまたは機器ログで ログイン・操作履歴を記録する |
| AAAサーバ1台故障でも 管理不能にならないこと | AAAサーバを冗長化し、 障害時の認証方式を定義する |
| 未許可端末を社内LANへ接続させないこと | 802.1X・RADIUS等を使用した ネットワークアクセス制御を検討する |
AAAサーバ障害時の設計
AAAで特に重要なのが、 AAAサーバへ接続できないときにどうするか という設計です。
集中認証を導入した結果、 AAAサーバ障害によって すべてのネットワーク機器へ管理ログインできなくなると、 障害復旧そのものが難しくなります。
AAAサーバを冗長化する
AAAサーバ冗長構成例
AAAサーバ自体を複数台構成にするだけでなく、 次の点も確認します。
- 各ネットワーク機器から両方のAAAサーバへ到達できるか
- ファイアウォールで必要な通信が許可されているか
- 経路障害時にも別経路から到達できるか
- サーバ切り替え条件は何か
- タイムアウト値は適切か
- 障害復旧後に自動復帰するか
ローカル認証を非常用として残す
ネットワーク機器管理では、 AAAサーバへ到達できなくなった場合に備えて ローカルアカウントを非常用として残す設計があります。
ただし、 「AAA認証に失敗したら無条件にローカル認証へ切り替える」 という設計には注意が必要です。
AAAサーバが明確に認証を拒否した場合まで 別方式で迂回できる設計にすると、 本来のアクセス制御を弱める可能性があります。
製品のAAAメソッドリストや フォールバック動作を確認し、 「サーバが応答しない場合」と 「認証を拒否された場合」 を区別して設計します。
Break Glassアカウント
通常運用では使用せず、 AAA基盤障害などの緊急時に限定して利用する 非常用管理者アカウントを準備する考え方もあります。
運用ルールには次の内容を含めます。
- 使用条件
- 資格情報の保管方法
- 利用承認者
- 利用後のパスワード変更
- 使用記録
- 定期的な利用可否確認
AAA設計のセキュリティポイント
1．共有管理者アカウントを通常利用しない
複数人が同じ
admin
アカウントを利用すると、
操作履歴を確認しても
実際に誰が操作したのか分かりません。
原則として個人を識別できるアカウントを使用し、 共有アカウントは必要性を確認した上で 用途を限定します。
2．最小権限を適用する
日常的な監視作業しか行わない利用者へ 最高権限を与える必要はありません。
業務上必要な範囲に権限を限定します。
3．管理経路を分離する
AAAを導入しても、 ネットワーク機器の管理ポートへ どこからでもアクセスできる構成では 攻撃対象が広がります。
管理用VLANや管理ネットワーク、 ACL、ファイアウォールなどを使用して 管理経路を制限します。
関連する考え方は、 「42. ファイアウォールポリシー設計」 でも扱っています。
4．AAAサーバとの通信を保護する
AAAサーバとの通信では、 使用プロトコル・製品が提供する セキュリティ機能を確認します。
共有秘密情報を使用する場合は、 推測されやすい文字列を使用せず、 適切に管理します。
5．時刻同期を行う
Accountingや監査ログを正しく追跡するには、 ネットワーク機器・AAAサーバ・ログサーバの 時刻が一致していることが重要です。
NTPなどを使用し、 時刻同期を設計します。
6．認証失敗を監視する
認証失敗が短時間に大量発生している場合、 単なるパスワード入力ミスではなく 不正アクセスや設定異常の可能性があります。
ログを保存するだけでなく、 必要に応じて監視・通知対象にします。
AAA設計でよくある失敗
AuthenticationとAuthorizationが 分離できていません。 利用者の役割に応じて必要な権限だけを付与します。
AAAサーバ障害によって 管理アクセスやネットワーク認証全体が停止する 単一障害点になる可能性があります。
AAAサーバへ接続できない場合に、 接続を拒否するのか、 制限付きで許可するのか、 ローカル認証を利用するのかを事前に決めます。
Accountingログにユーザー名が記録されても、 実際の操作者を特定できません。
ログは保存するだけではなく、 障害・監査・インシデント発生時に 検索できる状態にしておく必要があります。
AAAは認証サーバの設定ではなく、 ネットワークアクセス全体を制御する設計として考えます。
顧客・上司へAAAをどう説明するか
技術に詳しくない相手へ 「RADIUS」「TACACS+」「AAA」と説明しても、 導入する理由は伝わりにくい場合があります。
技術名ではなく、 業務上のリスクと結びつけて説明します。
説明例：
「現在はネットワーク機器へログインできる人が 同じ管理者権限を持っています。 AAAを導入すると、 誰がログインしたかを個人単位で確認し、 監視担当者には参照権限だけ、 構築担当者には必要な変更権限を与える、 といった管理ができます。 また、操作履歴を残すことで、 障害や不正操作が発生したときに 調査できるようになります。」
技術を業務リスクへ変換する
| 技術的な話 | 顧客へ説明する業務上の意味 |
|---|---|
| 集中認証 | 退職・異動時のアクセス権削除漏れを減らせる |
| Authorization | 誤操作や不要な高権限付与のリスクを減らせる |
| Accounting | 障害・不正操作時に原因を追跡できる |
| AAAサーバ冗長化 | 認証基盤障害による業務停止リスクを下げられる |
| 802.1X | 許可されていないPCを社内LANへ接続させにくくする |
上級工程では、 「この機能が使えます」 ではなく 「このリスクを減らすためにこの機能を使います」 と説明できることが重要です。
AAAで使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Authentication | 認証・本人確認 |
| Authorization | 認可・権限制御 |
| Accounting | 利用・操作履歴の記録 |
| Credentials | 認証情報 |
| Authentication server | 認証サーバ |
| Access policy | アクセスポリシー |
| Authorization policy | 認可ポリシー |
| Privilege | 権限・特権 |
| Least privilege | 最小権限 |
| Accounting record | 利用・操作記録 |
| Authentication failure | 認証失敗 |
| Fallback | 代替方式への切り替え |
設計・問い合わせで使える表現
Which authentication method is used for network administrators?
ネットワーク管理者にはどの認証方式を使用していますか？
What privileges should be assigned to each administrator group?
各管理者グループにはどの権限を付与する必要がありますか？
What should happen if the AAA servers are unavailable?
AAAサーバを利用できない場合、 どのような動作にする必要がありますか？
How long should accounting logs be retained?
Accountingログはどのくらいの期間保存する必要がありますか？
理解度チェック
用語暗記だけではなく、 認証・認可・Accountingを 実際の設計で区別できるか確認しましょう。
問題1．AAAのAuthenticationに該当するものはどれですか。
- 管理者が誰なのかを確認する
- 管理者が実行できるコマンドを制限する
- 管理者が実行したコマンドを記録する
- 管理者ログを1年間保存する
解答を見る
Authenticationは、 ユーザーや端末が誰なのかを確認する処理です。
問題2．監視担当者にはshowコマンドだけを許可し、 設定変更を禁止しました。 これはAAAのどれに該当しますか。
- Authentication
- Authorization
- Accounting
- Availability
解答を見る
認証された利用者へ 何を許可するかを決めるのがAuthorizationです。
問題3．管理者が何時にログインし、 どのコマンドを実行したか記録する機能はどれですか。
- Authentication
- Authorization
- Accounting
- Encryption
解答を見る
利用履歴や操作履歴を記録するのがAccountingです。
問題4．802.1Xによる有線LAN端末認証で 一般的に利用されるAAAプロトコルとして 最も適切なものはどれですか。
- RADIUS
- STP
- BGP
- SNMP
解答を見る
802.1Xの認証サーバとの通信では RADIUSが広く利用されています。
問題5．AAAサーバ障害への対応として 最も重要な設計はどれですか。
- AAAサーバを1台だけにする
- 障害時の認証動作を決めない
- サーバ冗長化と障害時動作を事前に決める
- 全管理者へ同じadminパスワードを教える
解答を見る
AAAはネットワーク管理や利用者接続に影響するため、 サーバ障害を前提に可用性を設計する必要があります。
問題6．次の文章の空欄を埋めてください。
AAAでは、 利用者が誰なのかを確認する（ A ）、 利用者が何を実行できるかを決める（ B ）、 利用状況を記録する（ C ）を組み合わせて アクセスを管理します。
解答を見る
A：Authentication
B：Authorization
C：Accounting
実践演習：企業ネットワークのAAAを設計する
次の企業へAAAを導入することになりました。 要件からAAA構成を考えてください。
現在の環境
- ネットワーク機器：50台
- ネットワーク管理者：10名
- 監視担当：5名
- 構築・運用担当：4名
- 管理責任者：1名
- 現在は複数人で共通のadminアカウントを使用
- 管理アクセスはSSH
- VPN利用者は200名
- AAAサーバは新規導入予定
顧客要件
- 管理者ごとに個人アカウントを使用したい
- 監視担当者には設定変更を許可したくない
- 誰が設定変更したか確認できるようにしたい
- AAAサーバ1台障害で管理不能にしたくない
- VPN利用者も集中認証したい
課題1．AAAの3要素へ分類する
次の要件を Authentication・Authorization・Accountingへ分類してください。
- 管理者ごとに個人アカウントを使用する
- 監視担当は設定変更できない
- 実行コマンドを記録する
Authorization：
Accounting：
課題1の解答を見る
- Authentication： 管理者ごとに個人アカウントを使用する
- Authorization： 監視担当は設定変更できない
- Accounting： 実行コマンドを記録する
課題2．AAAサーバ構成を考える
可用性要件を満たすため、 AAAサーバをどのような構成にしますか。
配置：
障害時動作：
非常用アクセス：
課題2の解答例を見る
- AAAサーバを2台以上用意する
- ネットワーク機器から両サーバへの到達性を確保する
- Primary障害時にSecondaryへ問い合わせる
- AAA基盤全体の障害へ備えて非常用ローカルアカウントを検討する
- 非常用アカウントの利用条件・保管・利用記録を決める
実際の構成は、 システムの可用性要件やAAA製品の仕様に合わせて決定します。
課題3．管理者権限を設計する
3つの管理者グループについて、 どのような権限を与えるか考えてください。
構築・運用担当：
管理責任者：
課題3の解答例を見る
- 監視担当： 状態確認・show系操作を中心とした参照権限
- 構築・運用担当： 担当業務に必要な設定変更権限
- 管理責任者： 高権限操作を含む管理権限
ポイントは、 「役職が高いから権限を与える」のではなく、 業務上必要な操作に合わせて最小権限を設計すること です。
課題4．設計レビューで説明する
顧客から次の質問を受けました。
「今まで共通のadminアカウントで問題なかったのですが、 なぜ個人アカウントとAAAが必要なのですか？」
説明例を見る
共通管理者アカウントでは、 設定変更が発生した際に実際の操作者を特定しにくくなります。 個人アカウントとAAAを導入することで、 管理者ごとに必要な権限だけを付与し、 誰がいつどの操作を行ったかを記録できます。 誤操作、不正利用、退職者の権限削除漏れなどの リスク低減につながります。
自分の言葉で説明する課題
後輩から 「AuthenticationとAuthorizationは何が違うのですか？」 と聞かれました。 30秒程度で説明してください。
Authorizationとは、＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
説明例を見る
Authenticationは、 アクセスしている人が本当に本人なのかを確認する処理です。 Authorizationは、 本人確認が終わった利用者に対して、 何を実行してよいかを決める処理です。
たとえば社員証を確認して本人だと判断するのがAuthentication、 その社員が入ってよい部屋を決めるのがAuthorization、 いつどの部屋へ入ったか記録するのがAccounting、 と考えると整理しやすくなります。
まとめ
- AAAはAuthentication・Authorization・Accountingの3要素から構成される
- Authenticationは「誰なのか」を確認する認証
- Authorizationは「何をしてよいか」を決める認可
- Accountingは「何をしたか」を追跡するための記録
- RADIUSは802.1X、VPN、ネットワークアクセス認証などで広く利用される
- TACACS+はネットワーク機器の管理者アクセスや細かな権限制御で利用される
- AAA設計では認証方式だけでなく権限・ログ・可用性まで設計する
- AAAサーバ障害時の動作と非常用アクセス方式を事前に決めておく
- 共有管理者IDではなく個人を識別できるアカウントを基本とする
- 権限は業務上必要な範囲へ限定し、最小権限を適用する
AAAの目的は「ログインさせること」ではありません。 誰がアクセスし、何を許可され、実際に何をしたのかを 一連の仕組みとして管理することが重要です。
あわせて読みたい関連記事
参考資料
AAA、RADIUS、TACACS+の仕様や製品実装を確認するときは、 ベンダー公式ドキュメントやRFCなどの一次情報を確認してください。
上級編では、要件定義・基本設計・高度なネットワーク技術・ クラウド・セキュリティ・自動化・提案までを順番に学びます。
コメント