Instiq
第2章 · ネットワークアクセス·v1.0.0·更新 2026/7/17·読了目安 約15分

変更要約: 初版

2.5管理アクセス

この節の要点

ネットワーク機器を運用管理するための接続経路——物理直結で帯域外のコンソール、暗号化のないTelnetと暗号化されるSSH、Web GUIのHTTP/HTTPS——と、それらへのログインを外部サーバで一元認証するAAAプロトコルのTACACS+(Cisco独自・TCP49・AAA分離・全ペイロード暗号化)とRADIUS(業界標準・UDP・認証と認可を統合)を、Cisco IOS の設定とともに学びます。

ルータやスイッチ、WLCを運用するには、機器のCLIやGUIへ安全に到達する経路を選び、そこへのログインを誰に許すかを制御しなければなりません。CCNAでは、帯域内(in-band)と帯域外(out-of-band)の違い、平文のTelnetと暗号化SSHの使い分け、そして各機器にローカルユーザを個別に持たせる代わりに外部の認証サーバでAAAを一元管理するTACACS+RADIUSの特徴が、設定・セキュリティの観点で問われます。

2.5.1コンソール・Telnet・SSH・HTTP(S)

  • コンソール=機器のコンソールポートにケーブルで直結してCLIへ入る帯域外(out-of-band)アクセス。ネットワーク疎通がなくても使えるため初期設定や障害復旧の最後の砦。設定は line console 0 で行う。
  • Telnet(TCP23)=ネットワーク経由(帯域内)でCLIへ入るが、ユーザ名・パスワード・操作が全て平文で流れるため盗聴に極めて弱く非推奨SSH(TCP22)=同じく帯域内だが通信全体が暗号化されるため、リモート管理はSSHを使うのが必須。VTY回線(line vty 0 15)で transport input ssh を指定すればTelnetを拒否しSSHのみ許可できる。
  • SSHを有効化するには、ホスト名とドメイン名を設定(hostname / ip domain-name)してからRSA鍵を生成(crypto key generate rsa)し、ローカルユーザ(username ... secret ...)とVTYの login local を組み合わせる。HTTP/HTTPS=Web GUIによる管理で、HTTPは平文・HTTPSは暗号化。WLCの管理は主にHTTPSのGUIで行い、機器側は ip http secure-server(HTTPS)を有効化し平文のHTTPは無効化するのが安全。

2.5.2AAAとTACACS+/RADIUS

  • AAA認証(Authentication:誰か)認可(Authorization:何を許すか)アカウンティング(Accounting:何をしたか記録)の3要素。各機器にローカルユーザを個別に持たせると管理が煩雑なため、外部の認証サーバで一元管理し、機器はログイン要求をそのサーバへ問い合わせる。
  • TACACS+Cisco独自のAAAプロトコル(TCP49)。認証・認可・アカウンティングを個別に分離して扱えるため、コマンド単位の細かな認可(どのユーザがどのコマンドを実行できるか)に強い。パケットのペイロード全体を暗号化する。ネットワーク機器の管理者アクセス制御に好まれる。
  • RADIUS業界標準のAAAプロトコル(UDP・認証/認可1812・アカウンティング1813)。認証と認可を1つのやり取りに統合し、パスワードのみを暗号化(他の属性は平文)。無線/有線のユーザ認証(802.1X)で広く使われる。
試験ポイント

「コンソール=帯域外・物理直結・最後の砦」「Telnet=平文・非推奨」「SSH=暗号化・リモート管理はこれ必須」をまず押さえます。AAAは「TACACS+=Cisco独自・TCP49・AAAを分離・ペイロード全体を暗号化」「RADIUS=業界標準・UDP1812/1813・認証と認可を統合・パスワードのみ暗号化」の対比が最頻出です。特に「暗号化範囲(TACACS+は全体/RADIUSはパスワードのみ)」「トランスポート(TACACS+はTCP/RADIUSはUDP)」「AAAの分離/統合」の3点でどちらか一方を選ばせる問題が典型です。

あるネットワークチームが、数十台のルータ・スイッチの管理者アクセスを見直しています。当初は各機器にローカルユーザを個別に作成し、リモート管理はTelnetで行っていましたが、Telnetは認証情報も操作も全て平文で流れるため、社内LANの盗聴で管理者パスワードが漏えいするリスクが指摘されました。まず全機器のVTY回線を transport input ssh に変更してSSHのみを許可し、ホスト名・ドメイン名の設定と crypto key generate rsa によるRSA鍵生成を行って暗号化されたリモート管理へ移行します(同時に平文HTTPを無効化しHTTPSのGUIに限定)。次に、機器ごとにローカルユーザを個別管理する運用は、担当者の入退社のたびに全機器を修正する必要があり煩雑なため、外部の認証サーバでAAAを一元化することにしました。ここで、要件は「管理者がどのコマンドを実行できるかをユーザ役割ごとに細かく制御(コマンド認可)したい」「認証情報だけでなく操作内容の記録も含めパケット全体を暗号化したい」というものです。この要件には、認証・認可・アカウンティングを分離して扱え、パケットのペイロード全体を暗号化するTACACS+(Cisco独自・TCP49)が最適です。一方、もし要件が「無線/有線のエンドユーザを802.1Xで認証したい」であれば、業界標準でマルチベンダーの認証基盤と相性が良いRADIUS(UDP1812/1813)を選びます。RADIUSは認証と認可を統合しパスワードのみを暗号化するため、コマンド単位の細かな管理者認可には向きませんが、大量のユーザ認証をシンプルに捌く用途に適しています。このように、機器管理者のアクセス制御にはTACACS+、エンドユーザ認証にはRADIUSという使い分けが、AAA設計の典型的な判断軸です。

項目TACACS+RADIUS
標準/独自Cisco独自業界標準
トランスポート/ポートTCP 49UDP 1812/1813
AAAの扱い認証・認可・アカウンティングを分離認証と認可を統合
暗号化範囲パケットのペイロード全体パスワードのみ
主な用途機器管理者のアクセス制御(コマンド認可)無線/有線のユーザ認証(802.1X)
注意

ひっかけ: 「RADIUSはパケット全体を暗号化するのでTelnet管理でも安全」は誤りです——RADIUSが暗号化するのはパスワードのみ(他の属性は平文)で、しかもRADIUSはログイン認証の仕組みであって管理経路そのものの暗号化ではありません。管理経路の暗号化はSSH/HTTPSの役割です。また「TACACS+はUDP、RADIUSはTCP」は逆=TACACS+がTCP49、RADIUSがUDP1812/1813です。さらに「コンソール接続はネットワーク経由の帯域内アクセス」も誤り=コンソールは物理直結の帯域外(out-of-band)で、ネットワーク疎通がなくても使えます。

コンソール/Telnet/SSHとTACACS+/RADIUSの図。
安全な管理経路と認証の一元化

2.5.3この節のまとめ

  • コンソール=帯域外・物理直結(初期設定/復旧の最後の砦)、Telnet=平文で非推奨、SSH=暗号化でリモート管理に必須(VTYで transport input ssh)、HTTP/HTTPS=Web GUI(HTTPSに限定)
  • AAA=認証・認可・アカウンティングを外部サーバで一元化。TACACS+=Cisco独自・TCP49・AAA分離・ペイロード全体を暗号化(機器管理者向け)
  • RADIUS=業界標準・UDP1812/1813・認証と認可を統合・パスワードのみ暗号化(無線/有線のユーザ認証=802.1X向け)。管理者アクセス制御はTACACS+、エンドユーザ認証はRADIUSが定石

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. あるチームが、社内LAN経由でルータをリモート管理する際、認証情報や操作内容が平文で流れて盗聴されるリスクを解消したい。管理経路の設定として最も適切なものはどれか。

Q2. ネットワーク機器の管理者アクセスをAAAサーバで一元管理する。要件は「管理者ごとに実行可能なコマンドを細かく制御(コマンド認可)したい」「認証情報だけでなくパケットのペイロード全体を暗号化したい」である。最も適したプロトコルはどれか。

Q3. TACACS+とRADIUSの特徴の比較として最も適切なものはどれか。

理解度を確認第2章「ネットワークアクセス」の問題を解く