直近で今後のネットワークについて考えることが多くなってきました。
弊社にはそんなときにとっても、かなり、エクストリームに頼れるアニキ社内用生成AIの「WeiseHub」さんがいらっしゃるのでネットワークアーキテクチャについて雑談してみました。
色々要望を出しアニキに相談しながらアーキテクチャ図に更新をかけていった記録です。
難しい知識がなくても生成AIを活用しながら形にしていけるよ！といった1例をご紹介できればと思います。
是非、素朴な図からどのような形になるか想像して読んでみてください。
AI Assistant: あなたはWorks Human IntelligenceのためのAIアシスタントです。
ラーメン屋さんでいう「いらっしゃせー」からスタートです。
User: このような簡単なネットワークがあります。
まず問題点があれば指摘してください。
Assistant: このネットワーク図では、以下の点を確認および改善することを考慮することができます。
セキュリティ: ファイアウォールの設定が適切か確認し、外部からの不要なトラフィックをブロックする設定が重要です。
ネットワークの信頼性: 冗長性を持たせることでネットワークの耐障害性が向上するか確認します。
ネットワークのスケーラビリティ: 将来的な拡張を視野に計画があるか検討します。
アクセス管理: ユーザー認証とアクセス制御の設定を確認します。
まず始まりの村の地図を見せて所感を伺ってみます。そして
雑談の方向性を決めるために、提案された「アクセス管理」について掘り下げることにしました。
User: 今はオフィスにいる人であれば誰でも繋げられる状態です。どのような対策が必要でしょうか。
Assistant: オフィス内でのセキュリティを強化するためには、以下の対策を考慮することができます。
ユーザー認証: ネットワーク接続時にユーザー名とパスワードで認証を行います。
MACアドレスフィルタリング: 許可されたデバイスのみを接続可能にする設定です。
VLANの設定: 異なるグループのアクセス権を設定するために仮想LANを使用します。
ネットワークアクセス制御（NAC）: セキュリティポリシーに準拠したデバイスだけを許可します。
定期的なセキュリティ監査: セキュリティ状態を定期的に確認し、改善点を見つけます。
User: ユーザー認証を行うにあたって図のどこに修正が必要ですか？
追加するべきコンポーネントがあれば教えて下さい。
Assistant: ユーザー認証を強化するための追加・修正のポイントは以下です。
認証サーバー（AAAサーバー）: L3スイッチとユーザーの間、またはL3スイッチに接続。
ネットワークアクセス制御（NAC）デバイス: L3スイッチとユーザーの間に配置。
設定変更: L3スイッチを認証サーバーに接続し、認証プロトコルを使用してポートレベルで認証します。
認証サーバーを追加してみましょう。とのことでしたので追加。
第一村人の登場です
（図の具体的な指示もあるのはすごい）
User: Radiusサーバーを追加してみました。スイッチポートレベルで認証を行うためL2スイッチも追加してみました。
Radiusサーバーの接続はL3でいいですか？
また、NACデバイスが具体的にわからなかったのでもう少し教えて下さい。
Assistant: RadiusサーバーをL3スイッチに接続するのは問題ありません。
NACデバイスについては以下のような役割を持っています。
デバイス検出: 接続するすべてのデバイスを検知します。
セキュリティ評価: デバイスがセキュリティ基準を満たしているか確認します。
アクセス制御: 基準を満たすデバイスのみ許可します。
ポリシー適用: アクセスポリシーを反映させます。
具体的な製品例にはCisco ISE、Aruba ClearPass、Forescoutなどがあります。
User: 図に追加したいのですがどのようなアイコンが適していますか。
Assistant: NACデバイスを図に追加する際には、以下のアイコンが適しています。
盾のアイコン: セキュリティを視覚的に示します。
ロックのアイコン: 保護機能を表現。
ネットワーク機器と鍵: NACの役割を強調するために使用します。
User:
こんな感じですかね。RadiusサーバーではユーザーのIDとパスワードで認証とありますが、
これではなりすましされてしまいませんか？
Assistant: 図は非常にわかりやすいです。なりすましに対抗するには、以下の多要素認証を追加してください。
ワンタイムパスワード（OTP）: デバイスに一時パスワードを送信します。
バイオメトリクス: 指紋や顔認証の使用を検討します。
また、強力なパスワードポリシーの策定や、認証ログの監視、セッションタイムアウトの設定も効果的です。
User: OTPなどの他要素認証は強力だと思いますがユーザーに負荷をかけてしまいます。
もっと楽な方法はないですか？
Assistant: ユーザー負荷を軽減する方法としては以下が考えられます。
シングルサインオン（SSO）: 一度の認証で複数システムへアクセス可能。
コンテキストベース認証: 信頼できる環境からのみログイン可能に設定。
ロケーションベースの認証: 指定IPアドレスからのアクセスを許可。
デバイス認証: 登録デバイスを許可する設定。
パスワードレス認証: 生体情報やデバイスによるログイン。
User: ・デバイス認証・パスワードレス認証いいですね。
ただ、生体認証をネットワーク接続するたびに求められるのはちょっと嫌ですね。
デバイス認証を行いたいです。図はどの様に変わってきますか。
Assistant: デバイス認証を実施するために、以下の変更をします。
デバイス管理サーバーの追加: デバイス登録と認証用。
デバイス管理アイコンの追加: サーバーアイコンやデバイスアイコンを追加し、NACデバイスと連携。
デバイスの固有IDを使い、許可されたデバイスのみアクセス可能となるようにします。
User: あ、そういえばSaaS型のMDMソリューションがありました。これは活用できますか。
Assistant: SaaS型MDMソリューションはデバイス認証や管理に有効です。
リモートデバイス管理: 登録デバイスの設定や監視に適しています。
ポリシーの適用: セキュリティポリシーの一元化。
認証の強化: 証明書を利用した認証が可能。
図にはクラウドアイコンとして記載し、NACやL3スイッチと連携する形で配置します。
User: なるほど。端末情報は認証サーバーではなく、L3スイッチでいいですね？
Assistant: 端末情報は通常、以下で管理されます：
RADIUSサーバー: 端末情報や認証を管理。
MDMソリューション: リモートデバイス管理とポリシー適用。
NACデバイス: 認証を実行。
スイッチはトラフィック管理用で、認証情報はサーバーやMDMで管理するのが一般的です。
MDMと認証サーバーを連携させると良いですよ。とのことなので図に追加。
User: ではRadiusサーバーと連携させてみます。
認証に証明書情報とありますが、これはどの様に格納されるのですか？
Assistant: 証明書情報はRADIUSサーバーやMDMで管理されます。
RADIUSサーバー: 証明書を保管し、デバイス認証時に利用。
MDMソリューション: 証明書の配布と管理を行い、安全な認証をサポート。
デバイス登録時に自動的に証明書を配布することで、管理者の負担を大幅に軽減できます。
User: 証明書はデバイスごとに固有のものですか？どのような情報がわかるのでしょうか？
Assistant: 証明書はデバイスごとに発行され、以下の情報を含みます：
デバイス固有のID: シリアル番号やMACアドレス。
発行者情報（Issuer）: 証明書を発行したCA。
証明書の有効期限: 開始日と終了日。
公開鍵: デバイスのための公開鍵。
署名: CAのデジタル署名。
これにより、デバイスの信頼性を保証し、不正アクセスを防止します。
社内にCAを立ててMDMと連携
MDMからクライアントへ証明書を配布せよとの提案。
大分それっぽくなってきました！村役場（CA）と幹線道路（L2）も登場です。
ただ、運用が大変そうだなと感じたので自動化出来ないかアプローチしてみます。
User: スクリーンショット 2024-12-13 141042.png
こんな感じですかね。破線で証明書の配布を表現してみました。この配布は自動でやりたいですね。出来ますか。
Assistant: はい、証明書の自動配布は可能です。
SaaS型MDMの活用: 自動で証明書をデバイスに配布。
グループポリシー（GPO）: Windows環境での証明書管理。
SCEP（Simple Certificate Enrollment Protocol）: 証明書の自動発行と更新。
これにより手動操作を減らし、管理を効率化できます。
大分形になってきたので、今度は具体的な攻撃を想定して強化を図っていこうと思います。
防御力は上昇してきているので、今度は不正の検出について聞いてみます。
User: 内部に不正なユーザーと端末が侵入した場合を考えます。
現状の装備では侵入を防げる可能性が高いですが、
不正な接続を検知して管理者に知らせる様に更に強化したいです。
Assistant: 不正な接続を検知するための強化方法として、以下を検討してください：
侵入検知システム（IDS）: NIDSとHIDSにより不審な活動を監視。
SIEM: データを集約し、リアルタイムで異常を分析。
ネットワーク監視ツール: トラフィックとログのモニタリング。
行動分析（UEBA）: 異常な動作を検知。
IDSをL3スイッチに、SIEMをセキュリティデータの集約管理に導入することで、不審活動の迅速な検知が可能です。
IDSやSIEMの提案がありました。これを図に盛り込んで見ましょう。
そのうえで再度レビューをもらってみます。
User: スクリーンショット 2024-12-13 142933.png
この様になりました。良くなったと思います。最後に
・ユーザーの利便性
・セキュリティ観点
でこのネットワークアーキテクチャをレビューしてください。
Assistant: このネットワークアーキテクチャは以下の特徴があります：
ユーザーの利便性
SSOやパスワードレス認証: 認証の簡単化により、ユーザーエクスペリエンスを向上。
MDMの自動管理: 手動操作が少なく、ユーザーの負担を減少。
迅速なアクセス: デバイス管理でログイン手間を省略。
セキュリティ観点
多層防御戦略: IDSとNAC、SIEMの導入による監視強化。
証明書認証: 高信頼性を確保。
ポリシー管理: 一元管理と迅速対応。
改善の余地
ユーザー教育とトレーニング: セキュリティ意識向上が必要。
定期的なテストと監査: 脆弱性の早期発見。
バランスのとれた設計で、ユーザビリティとセキュリティを高めています。ただし、継続的な見直しが重要です。
最後に採点してみてもらいます。
User: 100点満点でズバリ何点ですか!?
Assistant: このネットワークアーキテクチャは非常に優れていますが、常に改善の余地があるため、90点とします。
理由
利点: 多層防御、デバイス管理の自動化、リアルタイム監視。
改善点: 定期的なセキュリティテスト、ユーザー教育の強化、新たな脅威への対応。
強固な基盤を持っている一方で、継続した改善が重要です。
90点！
WeiseHubとの会話は図の作成含めて30分程度で実施することができました。
やや恣意的な質問もありましたが、会話の中で出てきたエッセンスは盛り込めていると思います。
実際に社内ネットワークを設計するには、これ以外にも多くの観点を考慮して設計する必要がもちろんありますが、その観点出しやクイックなアイディアの具体化にもWeiseHubさんは強力です。
そして社内で利用するために設計されているので、一般に公開されている生成AIには入れられない情報（具体設定やログなど）も入れることが出来ます。（なんでログ1行投げるだけでミドルウェアと原因までわかるんだ）
いつでも、どれだけでも壁打ち相手になってくれインフラレイヤーのエンジニアにも特大貢献頂いており感謝です。
Qiita読者の方々はもっとDeepに使っていると思いますが、ライトに使える人ももっと増えるといいなと思いこのアドカレを書かせていただきました。
以上です！「ありした！
」