5.1デバイスアクセス制御（lines・ローカル認証・AAA）

ネットワーク機器のセキュリティは、通過するトラフィックを守る前に機器そのものへのアクセスを守るところから始まります。特権パスワードを共有し全員が同じ enable を叩く運用では、誰が何をしたか追えず、退職者のアカウント失効もできません。ENCOR ではこの領域を、「lines（コンソール／VTY）にどの認証方式を紐づけるか」「AAA サーバをどう選び、落ちたときどう振る舞わせるか」「特権レベルやコマンド認可をどこで切るか」という運用設計として問われます。単に username を作るコマンドではなく、設定を投入した瞬間に自分が締め出されないかまで読み切る判断が本質です。

5.1.1lines とローカルユーザ認証

• 機器への管理アクセスはline（回線）単位で制御する。物理接続の line console 0、リモートの line vty 0 15、補助ポートの line aux 0 があり、それぞれ独立に認証方式を設定する。line vty 0 15 に login local を設定すると、username ADMIN privilege 15 secret <pass> で定義したローカルユーザデータベースのユーザ名＋パスワードで認証される。login のみ（password 併用）だとユーザ名のない共有パスワードになり、監査証跡が残らない。
• パスワード保存は secret（不可逆ハッシュ）を使い、password（可逆な Type 7 の弱い難読化）は避ける。enable secret で特権 EXEC を保護し、service password-encryption は Type 7 の難読化にすぎず強度の担保にはならない点に注意する。VTY には transport input ssh を設定して平文の Telnet を禁止し、ip ssh version 2 と RSA 鍵（crypto key generate rsa modulus 2048）を用意する。
• VTY への到達自体を絞るには、管理セグメントだけを許す ACL を access-class <ACL> in で line に適用する（インタフェース ACL ではなく line 配下に当てるのがポイント）。加えて exec-timeout 5 0 で放置セッションを切り、login block-for 系でブルートフォースを抑制する。

5.1.2AAA の3機能と適用

• AAA は3つの独立した機能からなる。認証（Authentication）＝「あなたは誰か」をユーザ名/パスワードや証明書で確かめる。認可（Authorization）＝「認証済みのあなたに何を許すか」を決める（EXEC シェルの特権レベル、実行可能なコマンド集合）。アカウンティング（Accounting）＝「誰がいつ何をしたか」を記録し、監査とインシデント調査の証跡にする。
• IOS では aaa new-model を有効にした上で、aaa authentication login default group tacacs+ local のようにメソッドリストを定義する。メソッドは左から順に評価され、前のメソッドが「応答しない」場合にのみ次へフォールバックする。つまりサーバが応答して「拒否」を返した場合は local に落ちない——この違いが障害時の挙動を分ける。
• 認可は aaa authorization exec default group tacacs+ local でシェル権限を、aaa authorization commands 15 default group tacacs+ local で特権コマンドを制御する。認可を有効にしたのにローカルのフォールバックを書き忘れると、サーバ到達不能時に認証は通るが EXEC シェルが開けないという半端な締め出しが起きる。コンソールを保険として aaa authentication login CONSOLE local を別メソッドリストにし、line console 0 に login authentication CONSOLE で紐づけるのが定石。

5.1.3TACACS+ と RADIUS の使い分け

• TACACS+ は TCP 49 を使い、認証・認可・アカウンティングを分離する。認可要求をコマンドごとにサーバへ問い合わせられるため、「この運用者には show 系のみ、あの運用者には設定変更まで」という粒度の細かいコマンド認可に向く。さらにパケット本体全体を暗号化するため、ユーザ名や実行コマンドまで盗聴から守られる。Cisco 独自だがデバイス管理の事実上の標準。
• RADIUS は UDP 1812（認証/認可）と 1813（アカウンティング）を使い、認証と認可を1つの交換に統合する。暗号化されるのはパスワード属性のみで、ユーザ名や他の属性は平文で流れる。標準（IETF）で拡張属性が豊富なため、802.1X によるエンドユーザ／端末のネットワークアクセス制御（ISE との連携、VLAN や SGT の動的割り当て）に広く使われる。
• 選定の原則は用途で分けること：機器管理（誰がどのコマンドを打てるか）は TACACS+、ネットワークアクセス制御（どの端末がどの VLAN に入れるか）は RADIUS。「RADIUS なら安全」「TACACS+ は古い」といった一般論ではなく、コマンド単位の認可が要るかと暗号化範囲が判断軸になる。

あなたはコアスイッチ群に TACACS+ による集中管理を導入し、aaa new-model、aaa authentication login default group tacacs+、aaa authorization exec default group tacacs+、tacacs server ISE を投入しました。適用直後は問題なく SSH でログインできましたが、翌日のメンテナンスで管理セグメントとサーバ間のルーティングに障害が起き、全スイッチに SSH でもコンソールでもログインできなくなりました。ここで「パスワードが変わったのでは」と疑うのは誤診です。原因はメソッドリストに local フォールバックが無いことに尽きます——group tacacs+ のみの場合、サーバが無応答になるとフォールバック先が存在せず認証が失敗し、しかも default メソッドリストは明示的に別リストを紐づけていない全ての line（コンソールを含む）に適用されるため、最後の砦であるコンソールも同時に塞がれたのです。正しい設計は二重の保険です。第一に aaa authentication login default group tacacs+ local と aaa authorization exec default group tacacs+ local のように必ず local を末尾に置き、対応するローカルユーザ（username ADMIN privilege 15 secret ...）を全機器に用意しておくこと。第二に aaa authentication login CONSOLE local という別リストを作り line console 0 に login authentication CONSOLE で紐づけ、コンソールだけは AAA サーバに依存させないこと。ここで「local を足すとセキュリティが下がるから避ける」という判断は誤りで、フォールバックはサーバが無応答のときにしか使われない（サーバが到達可能で拒否を返した場合には落ちない）ため、正規の拒否を迂回する穴にはなりません。さらに aaa accounting commands 15 default start-stop group tacacs+ を併せて入れておけば、復旧作業中に誰がどのコマンドを打ったかの証跡も残ります。設定投入の順序としても、AAA を有効化する前にローカルユーザと enable secret を作り、別セッションを開いたまま検証するのが実務の鉄則です。

5.1.4この節のまとめ

• line 単位で認証を紐づける：line vty に login local＋transport input ssh、到達制御は access-class を line 配下に適用し、パスワードは secret（ハッシュ）で保存する
• AAA は認証/認可/アカウンティングの3機能。メソッドリストは左から順に評価し、無応答のときのみ次へフォールバックするので、local を末尾に置きコンソール用の別リストを用意して締め出しを防ぐ
• TACACS+＝TCP 49・AAA 分離・全体暗号化＝機器管理のコマンド単位認可向き、RADIUS＝UDP 1812/1813・認証認可統合・パスワードのみ暗号化＝802.1X のアクセス制御向き