目次
1. 統合技術マップ（Technology Matrix）
本ロードマップを履修・構築することで習得できる技術、および顧客提案で提示するコンポーネントの一覧です。
| 分野 | 使用技術・プロトコル | 役割・提案価値 |
|---|---|---|
| Identity & Access | authentik / OIDC / LDAP / MFA | 認証一元化、SSO、パスキー（FIDO2）、多要素認証 |
| Authorization（RBAC） | authentik Groups → SAML/OIDC Claims | 属性・役割ベースのアクセス制御（営業/総務/開発の権限分離） |
| Hybrid Storage | Samba / Nextcloud / WebDAV | LAN内超高速SMB ＋ リモートWeb共有 ＋ ブラウザOffice編集 |
| Network & Firewall | FortiGate / Caddy / TLS（Let's Encrypt） | マイクロセグメンテーション（DMZ/SERVER/HOME）、TLS自動終端 |
| ZTNA（Zero Trust） | OpenZiti / Headscale | インバウンドポート全閉、Identity-Firstなアプリ単位アクセス |
| Observability | Prometheus / Loki / Promtail / Grafana | ログ・メトリクス・トレースの一元可視化、SIEM、ジオIPマップ |
| Availability（自律復旧） | Podman / Quadlet / systemd | コンテナ自動再起動、障害検知時のSelf-Healing |
| Platform Engineering | Ansible / Gitea / Vaultwarden | IaC（コードによるインフラ化）、GitOps、Secrets（暗号）管理 |
| Security & EDR | Wazuh / Fail2ban / SELinux / SPF・DKIM | 端末・サーバの改ざん検知、EDR、攻撃自動BAN |
| AIOps & RAG | OpenWebUI / Ollama / Loki-AI | AIログ要約、社内ドキュメントRAG検索、運用自動支援 |
| Backup & DR | Restic / BorgBackup / Snapshots | 世代管理暗号化バックアップ、ランサムウェア復旧 |
2. アーキテクチャの4層構造 ＋ RBAC（認可制御）モデル
単に「ログインできる（Authentication）」だけでなく、「誰が何にアクセスできるか（Authorization）」を制御する4層積層モデルです。
grp_sales / grp_eng / grp_admin）3. フェーズ別設計ロードマップ（Phase 0〜5）
各フェーズは【5つの統一項目】＋【Definition of Done（完成条件）】で整理しています。
基盤可読性＆信頼性確立（Foundation）
なぜこれが必要か
今起きている問題：サーバー同士の時刻がわずかにずれるだけで認証が失敗したり、DNS（名前解決）が1つ止まっただけで、関係のないはずのサービスまで道連れで止まってしまう。土台そのものがもろい状態。
導入すると変わること：時刻同期・名前解決・コンテナの管理を、「壊れないようにする」のではなく「壊れても自動で立ち直る」仕組みに作り替える。
メリット：この土台があって初めて、以降のPhase 1〜5を安心して積み上げられる。逆にここを飛ばすと、後になるほどトラブルの原因究明が難しくなる。
顧客課題
NTPのズレによるOIDC認証失敗、DNS停止による全サービスダウン、障害時の手動復旧不可。
ソリューション
Unbound（Split-DNS） / Chrony / FortiGate ACL / Podman Quadlet（systemd統合）。
設計ポイント
全コンテナを Quadlet（systemd）で管理し、Restart=always によるコンテナ自律復旧（Self-Healing）を実装。
運用・バックアップ
Ansible Playbook と Quadlet 設定ファイルを Gitea へコミット（GitOps）。
完成条件（DoD）
- 全サーバの時刻同期差が1秒未満であること
- 内部FQDNの名前解決とTLS証明書の自動更新が正常動作すること
podman killでコンテナを強制終了しても、systemdにより数秒で自律復旧すること
実施記録
2026年8月1日、IP設計（192.168.2.0/24ゾーニング）・DNS/NTP（Unbound＋Chrony）のQuadlet化・SELinux運用・3点通信検証までを実機で構築・検証し、DoDを達成しました。詳細な手順とエビデンス（dig / chronyc実行ログ）は「Phase 0 実践構築・運用マスターマニュアル」を参照してください。
ハイブリッドストレージ ＆ ゼロトラスト認証・認可（RBAC）
なぜこれが必要か
今起きている問題：社内のファイル共有と、社外からのリモートアクセスを別々の仕組みで管理していると、「誰がどのフォルダにアクセスできるか」を把握しきれなくなる。退職者のアカウント消し忘れなどの事故も起きやすい。
導入すると変わること：ログインの仕組み（authentik）を1つに統一し、「このグループの人はこのフォルダだけ」というルールを、社内アクセスにも社外からのアクセスにも同じ基準で適用する。
メリット：権限管理が1箇所で完結し、消し忘れ・付け忘れの事故を防げる。外出先からでも、社内と同じ安全な手順でファイルにアクセスできるようになる。
顧客課題
社内SMBと社外リモート環境で二重管理が発生。部署ごとのアクセス権限設定が煩雑。
ソリューション
authentik（IdP） ＋ Samba ＋ Nextcloud ＋ OnlyOffice。
設計ポイント（RBAC）
- authentik上のグループ（例：
grp_sales）を NextcloudのグループおよびSambaのPOSIX ACLに自動同期。 - 営業部は「営業資料フォルダのみ（閲覧・編集）」、総務部は「全フォルダ」へアクセスできるよう認可を統一。
運用・バックアップ
Sambaストレージ（/srv/samba）を Restic で暗号化し、別セグメントへ日次差分バックアップ。
完成条件（DoD）
- authentikでログイン後、所属グループに応じたフォルダのみがNextcloud/Sambaで表示されること
- MFA（TOTP/Passkey）が強制され、ブラウザ上でOffice文書が共同編集できること
実施記録
2026年8月3日にSamba基盤（LAN内DoD）を構築、2026年8月6日にauthentikのOIDCプロバイダー構築・Headscale VPN連携（NATループバック問題の解消含む）・Samba利用者Aユーザーの恒久化を実機で実施し、さらに外部端末からの実地接続テストでサブネットルーター・firewalld・DERPリレー・ACLポリシー・ファイルパーミッションの5つの追加課題を解消のうえ、書込・読込・削除までの完全動作確認を完了しました。2026年8月11日には、TOTP多要素認証（MFA）をHeadscaleアプリの認証フローに組み込み、外部端末からのログイン（VPN参加）でMFAコードの入力が要求されることを実機確認しました。authentikグループとNextcloud/Samba ACLの自動同期、ブラウザ上でのOffice共同編集は未実施です。詳細な手順とエビデンスは「Phase 1 Samba基盤構築マニュアル」、「Phase 1 authentik連携 実践マニュアル（Headscale／Samba編）」、および外出先からの接続手順をまとめた「外出先から自宅ネットワークへ安全に接続する（ワンタイムパスワード）」運用ガイドを参照してください。
次世代 Observability ＆ 自律復旧（AIOps前段）
なぜこれが必要か
今起きている問題：障害が起きたとき、どのサーバーの何のログを見ればいいか分からず、原因究明に時間がかかる。サービスが落ちても誰も気づかず放置されることもある。
導入すると変わること：すべてのサーバー・機器のログを1か所に集約して横断検索できるようにし、異常が起きた瞬間にSlackへ自動で知らせる仕組みを作る。
メリット：障害の発見から原因特定までの時間が大幅に短縮される。人が気づくより先に、システム自身が「壊れた→直った」を通知してくれるようになる。
顧客課題
ログが分散し障害原因の特定が遅れる。サービス停止時に手動介入が必要。
ソリューション
Promtail → Loki / Prometheus → Grafana / systemd Auto-Restart。
設計ポイント（Availability）
- 監視 → 検知 → 自動復旧 → 通知 パイプラインの構築。
- プロセス停止検知時、systemdが自律再起動を実施。復旧ログおよび再起動アラートをGrafana経由でSlack/Teamsへ通知。
運用・バックアップ
Lokiログのホット（SSD 30日） / コールド（S3/MinIO 1年）ストレージ自動移送。
完成条件（DoD）
- FortiGate、Web、DB、OSの全ログがLokiでリアルタイム検索できること
- 攻撃検知（Fail2ban BAN時）およびサービス自律再起動時に、数秒で通知が届くこと
実施記録
2026年8月13日、Prometheus/Loki/Promtail/GrafanaをAlmaLinuxに集約構築し、FortiGate・Web（Apache）・DB（authentik-db等のコンテナログ）・OS（両ホストのjournald）の全ログをLokiで横断検索できることを実機確認しました。systemdサービスの自律復旧とSlack通知の連携も、実際にコンテナを強制終了してから60秒以内に通知が届くことまで実測済みです。一方、Fail2ban BAN検知のアラートルールは作成・設定済みですが、実際のBAN発生による通知到達はまだ実機確認していません。またRocky Linux側のメトリクス収集とGrafanaの外部公開（Caddy経由・authentik SSO連携）、Lokiログのコールドストレージ自動移送は、境界ファイアウォールの既知の不具合等により未実施のまま保留しています。詳細な手順とエビデンスは「Phase 2 Observability実践マニュアル」を参照してください。
Identity-First ゼロトラストアクセス（ZTNA）
なぜこれが必要か
今起きている問題：VPNは「一度繋がった端末は社内ネットワーク全体に到達できる」仕組みのため、1台がマルウェアに感染すると、被害が社内全体に広がりやすい（この広がり方を「ラテラルムーブメント＝横移動」と呼ぶ）。
導入すると変わること：「ネットワークに繋ぐ」のではなく「許可された特定のアプリだけに繋ぐ」方式に変える。外部からはアクセス用のポートが一つも見えない状態にする。
メリット：万が一端末が乗っ取られても、攻撃者が到達できる範囲は許可されたアプリ1つだけに限定される。外部から見た侵入口そのものも存在しなくなる。
顧客課題
全対全VPNによるランサムウェアの横移動（ラテラルムーブメント）リスク。
ソリューション
OpenZiti（ZTNA） ＋ authentik（Identity）。
設計ポイント（Identity-First）
- ［Identity］authentikで認証 → ［Device］Ziti Client証明書を検証 → ［Policy］認可ポリシー評価 → ［App Access］許可されたアプリ（Nextcloud等）のみ接続。
- インバウンドポート（445, 22等）は外から一切見えない「ダークネットワーク」化。
運用・バックアップ
OpenZiti コントローラのポリシー設定・PKI（証明書基盤）のバックアップ。
完成条件（DoD）
- FortiGateのインバウンドVIP（ポート開放）を全閉した状態で外部アクセスができること
- 許可されていない端末や、認可されていないポート（SMB 445等）へのアクセスが完全に遮断されること
Platform Engineering ＆ シークレット管理
なぜこれが必要か
今起きている問題：パスワードやAPIキーが設定ファイルにそのまま書かれていたり、「誰がいつ何を変更したか」の記録が残っていないと、情報漏えいや誤操作が起きたときに原因調査ができない。
導入すると変わること：パスワード類を専用の金庫（Vaultwarden）で一元管理し、インフラの設定変更はすべてコード化してGitで履歴管理する。不正な変更は改ざん検知（Wazuh）で監視する。
メリット：「誰が・いつ・何を変えたか」が必ず記録に残り、パスワードの使い回しや漏えいのリスクも大きく下がる。
顧客課題
パスワードの平文管理、設定ファイルの野良改修、セキュリティ脅威の見落とし。
ソリューション
Vaultwarden（Secrets） / Gitea（GitOps） / Wazuh（EDR/SIEM）。
設計ポイント
- APIキーやDBパスワードを Vaultwarden で暗号化集中管理し、Ansible実行時に動的取得。
- Wazuh Agentを全サーバに導入し、ファイル改ざん・CVE脆弱性・不正プロセスをリアルタイム監視。
運用・バックアップ
Vaultwardenの暗号化DBの日次3重バックアップ（ローカル/NAS/クラウド）。
完成条件（DoD）
- GiteaへのコードPushによりインフラ設定が自動テスト・デプロイされること
- Wazuhダッシュボードで全サーバのOS脆弱性と改ざん検知スコアが可視化されること
AI運用支援（AIOps） ＆ 社内ナレッジRAG活用
なぜこれが必要か
今起きている問題：障害ログの解析には専門知識が必要で、対応できる人が限られる。社内マニュアルも散らばっていて、必要な時に見つからない。
導入すると変わること：社内のドキュメントをAIに学習させ、質問すればマニュアルの内容をもとに答えてくれるようにする。エラーログもAIが要約し、対応の候補まで提示する。
メリット：専門知識がなくても一次対応ができるようになり、「その人しか対応できない」状態（属人化）を防げる。データは外部に一切送らず自宅内だけで処理するため、情報漏えいの心配もない。
顧客課題
障害ログの解析に専門知識（SEのスキル）が必要。社内規定や障害対応マニュアルが散逸し検索できない。
ソリューション
- LLM Engine：Ollama（ローカルLLM） / OpenWebUI
- Knowledge RAG：Nextcloud/Samba内のドキュメント（PDF/Word/Wiki）をOpenWebUIのRAGに自動学習
- Log AI Analysis：LokiのエラーログをLLMに投入し、「要約 ＋ 原因候補 ＋ 復旧手順」を自動生成
設計ポイント
- データ漏洩を防ぐため、外部API（OpenAI等）を使わず完全オンプレミスLLM（Llama3 / Qwen等）で処理。
- OpenWebUIの認証を authentik（OIDC）に統合し、RAGの参照権限をPhase 1のRBAC（部署権限）と連動。
運用・バックアップ
RAG用ベクトルデータベース（ChromaDB/pgvector）の定期インデックス再生成。
完成条件（DoD）
- OpenWebUIにauthentikでログインし、社内マニュアル（Samba内PDF等）に基づいた回答が返ること
- Grafana/Loki上で発生した複合エラーログをAIが要約し、推奨対応策を提示できること
4. Disaster Recovery Lab（障害シナリオ・復旧演習 7選）
企業が最も高く評価する「障害時にどう復旧するか」を検証するための演習マニュアルです。
| 演習コード | 障害カオスシナリオ | システムへの影響 | 検証内容＆復旧手順 |
|---|---|---|---|
| DR-01 | authentik（IdP）停止 | SSO認証・OpenZitiログイン不可 | 検証：キャッシュ生存確認。復旧：緊急ローカル管理者用バックドア（Caddy直受バイパス）でのアクセスとQuadlet再起動。 |
| DR-02 | 内部DNS（Unbound）停止 | 全内部FQDN名前解決不可、TLS更新失敗 | 検証：Split-DNS障害時の影響範囲確認。復旧：Chrony/Unboundの冗長化構成への切り替え確認。 |
| DR-03 | Sambaストレージダウン | Nextcloud外部ストレージエラー | 検証：データ破損の有無とエラーハンドリング確認。復旧：Resticバックアップからのポイントインタイム・リストア手順の実行。 |
| DR-04 | TLS証明書 期限切れ | ブラウザ警告、OIDC通信拒否 | 検証：CaddyのACMEチャレンジ手動実行と、証明書強制更新スクリプトの動作確認。 |
| DR-05 | Lokiログ集約停止 | ログ検索不可、アラート停止 | 検証：Promtail側のローカルバッファ（キュー）保持動作確認。復旧：Loki復旧後の未送信ログ再送確認。 |
| DR-06 | FortiGate ACL 設定ミス | セグメント間通信全遮断 | 検証：FortiGateのコンソール接続からのSafe-Config（リバート）復旧手順。 |
| DR-07 | ランサムウェア攻撃想定 | Samba共有ファイルの暗号化 | 検証：Wazuhによる異常書き込み検知（即時プロセスKill）と、ZFS/Resticスナップショットからの1秒復旧。 |
5. 業界別・顧客提案モデル（営業・提案資料用）
脱VPN ＆ ランサムウェア遮断パッケージ
提案内容：OpenZiti（ZTNA） ＋ Wazuh（EDR） ＋ Samba
効果：外部公開ポートゼロで工場・拠点を接続。仮に端末が感染してもWazuhが検知し、ZFSスナップショットで復旧。
現場リモートワーク ＆ 現場写真即時共有パッケージ
提案内容：Nextcloud ＋ OnlyOffice ＋ authentik（MFA）
効果：現場のスマホから図面・写真を即時閲覧・編集。authentikにより協力会社アカウントのセキュリティを担保。
ISMS/監査ログ統合 ＆ AI運用支援パッケージ
提案内容：Loki ＋ Grafana ＋ OpenWebUI（AIOps/RAG）
効果：統合ログ保存（J-SOX/ISMS対応）に加え、蓄積されたログや運用マニュアルをAIが即座に解析・サポート。
6. SEとしての成果物（ポートフォリオ）作成ガイド
このロードマップを完了した際、手元に残る成果物セットです。
- 全体統合構成図（L1物理/L2ネットワーク/L3アプリケーション/認可フロー）
- Podman Quadlet ＆ Ansible Playbook リポジトリ（IaCとして完全コード化されたインフラ）
- Grafana 統合監視ダッシュボード（SOC/NOC画面のキャプチャと設定JSON）
- Disaster Recovery 障害対応エビデンス（DR-01〜07の障害発生〜復旧までのログと手順書）
- 顧客向け提案スライド（10〜15ページ）（本ロードマップの「課題→解決→構成→効果」をパワポ化）
結び
本ロードマップは、単なる技術のまとめではなく、現代のエンタープライズITが求める要素（Zero Trust, Observability, Platform Engineering, AIOps, DR）が1つのストーリーとして繋がった設計図です。自宅検証環境（Lab）でフェーズを1つずつ動かし、壊し、復旧させる体験こそが、現場で信頼を得るインフラSEとしての実力になります。