Phase 1 | Week 5: 仮想化とセキュリティ | プロジェクト・ミーミル

仮想化と Web セキュリティの基礎を、原理から説明できる状態に落とし込む勉強会の資料です。

カーネルとスレッドモデルから入り、コンテナが「カーネル機能を使ったプロセス隔離」であることと Docker の基本を扱います。後半は Web の主要な攻撃手法（XSS や SQL インジェクションなど）とその対策、そして認証と認可の違いと使い分けを順番に押さえます。

ねらいは、用語を覚えるのでなく「なぜコンテナが軽量か」「なぜその攻撃が成立し、どう防ぐか」を自分の言葉で説明できる状態にすること。候補者が仕組みのレベルで語れているかを見分ける観点も合わせて示します。

▼ プロジェクト・ミーミルとは
TLE（テックリードエンジニア）および技術面接官の育成を目的としたプログラムです。コンピュータ・ネットワーク・Web の基礎を体系的に学び直し、暗記ではなく「なぜそうなっているか」を自分の言葉で説明できる状態を目指します。週1回の勉強会で基礎から専門領域までを順番に扱い、技術面接で候補者の力を原理から正しく評価できる面接官を育てます。

Transcript

1. Week 5: 仮想化 + セキュリティ プロジェクト・ミーミル Phase 1 / 全15回 プロジェクト・ミーミル | Week 5 1
2. 今日のゴール 1. カーネルとスレッドモデルを自分の言葉で語れる 2. コンテナがカーネル機能を使ったプロセス隔離であることを理解し、Docker の基 本を説明できる 3. Web の主要な攻撃手法と認証・認可の違いを説明できる プロジェクト・ミーミル | Week 5 2
3. 今日のアジェンダ 時間 パート 分 0:00 Week 4 振り返り 5分 0:05 カーネルとスレッドモデル深掘り 15分 0:20 仮想化・コンテナ・Docker 20分 0:40 Web セキュリティ・認証認可 15分 0:55 まとめ・次回予告 5分 プチテストは時間外（Notion フォームで次回までに各自） プロジェクト・ミーミル | Week 5 3
4. Week 4 振り返り プロセスとスレッド: 同じプロセス内のスレッドはメモリを共有する データ競合: 「気づかないうちにデータが壊れる」のが一番怖い（ go run -race で検出可能） 排他制御: ミューテックス・セマフォ・チャネル。Go なら sync.Mutex が基本 → 今日はこのプロセスの話の延長線上で、カーネル・コンテナ・セキュリティへ プロジェクト・ミーミル | Week 5 4
5. 復習: counter++ はなぜ壊れる？ var counter int for i := 0; i < 1000; i++ { go func() { counter++ }() // ← なぜ壊れる？ } 内部で 何ステップ に分かれている？ なぜ値が 意図せず上書き される？ → 〇〇さん、覚えていますか？ プロジェクト・ミーミル | Week 5 5
6. カーネルとスレッドモデル Week 4 の深掘り。コンテナ理解の前提 プロジェクト・ミーミル | Week 5 6
7. カーネルとは OS の中核。ユーザープログラムとハードウェアの間に立つ やっていること 例 プロセス・スレッド管理 スケジューリング、コンテキストスイッチ メモリ管理 仮想メモリ、ページング I/O 管理 ファイル、ネットワーク、デバイス システムコール提供 read() , write() , open() 等 プロジェクト・ミーミル | Week 5 7
8. カーネルモード vs ユーザーモード ユーザーが書くコードは直接ハードウェアを触れない → システムコール経由でカーネルに依頼する [アプリケーション] ← ユーザーモード（制限あり） │ ↓ システムコール │ [カーネル] ← カーネルモード（ハードウェア操作OK） │ ↓ [ハードウェア] 例: fmt.Println() → Go ランタイム → write() システムコール → カーネル → 画面 出力 プロジェクト・ミーミル | Week 5 8
9. スレッドモデル比較 種類 管理者 切替コスト 例 カーネルスレッド OS（カーネル） 重い（システムコール） pthread, Java Thread ユーザーランドスレ ッド アプリ／ランタ イム 軽い（ユーザー空間で 完結） グリーンスレッド M:N（ハイブリッ ド） 両方 中間 Go goroutine, Erlang M:N スケジューラ: 多数の goroutine（M）を少数の OS スレッド（N）に多重化（M ≫ N） I/O 待ちで他の goroutine に切替 → ブロッキングしない プロジェクト・ミーミル | Week 5 9
10. コンテキストスイッチとは コンテキストスイッチ = 今動いている処理を一旦止めて、CPU やメモリの状態を 保存し、別の処理に切り替える動作 切替対象は 3 種類: プロセス切替（重い） スレッド切替（軽い） goroutine 切替（さらに軽い） → なぜコストが違う？ 次のスライドで中身を見ていく プロジェクト・ミーミル | Week 5 10
11. コンテキストスイッチの中身 プロセス切替（重い） レジスタ保存 + メモリ周りの設定を全部入れ替え（仮想メモリの設定、関連キャ ッシュのクリア等） スレッド切替（軽い） レジスタ保存だけ。メモリ周りはそのまま（同じプロセス内なので） goroutine 切替（さらに軽い） ユーザー空間でスタック切替するだけ。OS を介さない → だから Go は数万 goroutine 同時に動かせる プロジェクト・ミーミル | Week 5 11
12. 面接問題①: スレッドモデル 候補者にこう尋ねます: 「スレッドには大きく カーネルスレッド・ユーザーランドスレッド・ハイブリッ ド（M:N） の3種類があります。それぞれの違いを説明してください。Go の goroutine はどれに該当しますか？ また、その特性から 1万個立てても動く理由 も説明してください。 」 面接官として引き出したいのは、3種類の区別と goroutine が M:N であることの理解で す。 皆さん、候補者からどう引き出しますか？ プロジェクト・ミーミル | Week 5 12
13. 面接問題①: 良い回答 / 不十分な回答 良い回答: カーネルスレッド = OS 管理（pthread / Java Thread） ユーザーランドスレッド（グリーンスレッド）= ランタイム管理、単一 OS スレッ ド上 ハイブリッド（M:N） = ユーザーランド管理 + 複数 OS スレッドに多重化 goroutine はハイブリッド（M:N） 。切替が軽い + 数 KB なので大量に立てられる 不十分な回答: 「goroutine はユーザーランドスレッドだから軽い」 goroutine = ユーザーランドスレッドと誤解（マルチコア活用不可になる） M:N（複数 OS スレッドに多重化） への言及がない プロジェクト・ミーミル | Week 5 13
14. 仮想化・コンテナ・Docker カーネル機能を使ったプロセス隔離 プロジェクト・ミーミル | Week 5 14
15. 仮想化 = プロセス隔離の強化版 Week 4 で学んだ: プロセスは独立したメモリ空間を持つ → じゃあ「ファイルシステム」 「ネットワーク」 「プロセスID」も隔離したら？ → それがコンテナ Linux カーネルの仕組みで実現: namespaces: プロセス・ネットワーク・ファイルシステム等の名前空間を分離 cgroups: CPU・メモリ・I/O のリソース制限 プロジェクト・ミーミル | Week 5 15
16. コンテナ vs VM [VM] [Container] +----------------+ +----------------+ | App | | App | | Libraries | | Libraries | +----------------+ +----------------+ | Guest OS | | (Shared Host) | | (Full OS) | | | +----------------+ +----------------+ | Hypervisor | | Runtime | +----------------+ +----------------+ | Host OS | | Host OS | +----------------+ +----------------+ heavy, slow boot light, fast boot コンテナ = OS を共有しつつプロセス単位で隔離 プロジェクト・ミーミル | Week 5 16
17. Docker の重要概念 イメージ vs コンテナ イメージ = 設計図（静的）／ コンテナ = 実行中のインスタンス（動的） → 設計図と、それを元に建てられた建物の関係 レイヤー構造とキャッシュ Dockerfile の各命令が変更を記録したレイヤーとして積み重なる（Git のコミット 履歴に近い） 同じ内容のレイヤーは キャッシュから再利用 → 変更があったレイヤー以降だけ再 ビルド だから 変更頻度の低いものを上、高いものを下 に書くのがビルド速度を上げる基 本 プロジェクト・ミーミル | Week 5 17
18. Docker 運用の判断軸 判断軸 やること 目的 マルチステージビル ド ビルド用と実行用のステー ジ分離 本番イメージのサイズ削減 ベースイメージ選定 alpine / distroless / scratch など サイズ + 攻撃面の削減 + デバッ グ容易性 レイヤー順序の最適 化 変更頻度の低い命令を先に キャッシュの有効活用 .dockerignore 不要ファイルを除外 サイズ削減 + secrets 誤入り防止 distroless / scratch : シェル・パッケージマネージャなし → 万が一侵入されても 任意コマンド実行が困難 = 攻撃面が小さい プロジェクト・ミーミル | Week 5 18
19. コンテナセキュリティ — よくある落とし穴 1. 古いイメージ・古いバージョンを使い続ける 新しい脆弱性（CVE: 知られてる脆弱性につく番号）が積み上がる → イメージの自動スキャン（Artifact Registry / ECR）＋ バージョン更新運用 2. コンテナに権限を盛りすぎる root 起動 → 侵入時の被害がホストまで広がる → root じゃなく一般ユーザーで起動 ＋ ネットワークを区切る 3. Secrets をイメージや環境変数に焼き込む パスワード・API キーがレジストリや Git から見える状態に → 暗号化保管 ＋ Secret Manager 段階移行 ＋ 自動スキャン プロジェクト・ミーミル | Week 5 19
20. 面接問題②: コンテナ vs VM ここまでコンテナと Docker を見てきましたが、これを面接でどう活かすかを見ていき ます。 皆さんが面接官として、候補者にこう質問するとしましょう: 「コンテナと仮想マシンの違いを説明してください。コンテナはなぜ軽いんです か？」 面接官として引き出したいのは、 「OS を共有する」点とカーネル機能（namespaces / cgroups）への言及です。 皆さん、候補者からどう引き出しますか？ プロジェクト・ミーミル | Week 5 20
21. 面接問題②: 良い回答 / 不十分な回答 良い回答: 「VM はゲスト OS を丸ごと立てるのに対し、コンテナは ホスト OS のカーネル を共有 して、Linux の namespaces / cgroups でプロセス単位に隔離 する。だか ら起動が速くてリソースも少ない。 」 不十分な回答: 「コンテナは Docker で動くから軽い。VM は重い仮想化技術」 Docker は ツールであって仕組みの説明ではない なぜ軽いかのメカニズム（カーネル共有・namespaces/cgroups）への言及がな い 運用上の判断（ベース OS の脆弱性影響範囲等）ができない プロジェクト・ミーミル | Week 5 21
22. Web セキュリティ・認証認可 攻撃手法と認証・認可の使い分け プロジェクト・ミーミル | Week 5 22
23. 主要な Web 攻撃手法（OWASP Top 10 2025 順） 攻撃 OWASP 2025 2026 の文脈 対策 CSRF A01 内包 AI ブラウジングエージェントの 代理操作 CSRF トークン、 SameSite SQL Injection A05 Injection AI 生成コードの文字列連結 パラメータ化クエリ XSS A05 統合 LLM 出力 Markdown の HTML 描 画 エスケープ、CSP 認証バイパ ス A07 認証失 敗 AI エージェントへの権限過剰 認可チェック徹底 2025 版の注目点: A03 が Software Supply Chain Failures に格上げ（OWASP Top 10 プロジェクト・ミーミル | Week 5 23
24. XSS の対策 最近の動向: AI が出力した内容をそのまま画面に出すケースが増え、新しい入口に 取るべき対策（複数を組み合わせる）: ユーザー入力や AI 出力は、画面に出す前に エスケープ する HTML を直接書き換える危険な操作は避ける 不要なタグや属性を 取り除く ブラウザレベルで 実行できるスクリプトを制限 する 1 つで完璧にしようとせず、複数の対策を重ねる のが基本 プロジェクト・ミーミル | Week 5 24
25. 認証 vs 認可 認証（Authentication） 認可（Authorization） 問い あなたは誰？ あなたに権限はある？ 例 ログイン（ID + パスワード） この記事を編集できる？ HTTPステータス 401 Unauthorized 403 Forbidden 手法 パスワード、OAuth、SSO RBAC、ABAC 「認証OK → 認可チェック」の順 で処理する プロジェクト・ミーミル | Week 5 25
26. OAuth（第三者アプリに代わりにアクセスさせる仕組み） 例: 「Google でログイン」 「GitHub でログイン」 2026: 新バージョン OAuth 2.1 が標準に。より安全な使い方に整理された JWT（OAuth が発行するトークンの定番）: 署名つきの形式で、改ざんは防げる 中身はデコードすれば誰でも読める → 秘密情報を入れない 一度発行すると有効期限まで取り消せない → ログアウト設計に工夫が要る プロジェクト・ミーミル | Week 5 26
27. Passkey（パスワードを使わない次世代の認証） 2024-2026 で一気に普及: Apple / Google / Microsoft が全社で推進 最大のメリット: 「漏れるパスワード」というものが消える → フィッシング詐欺も効きにくくなる 端末間同期にも対応（iCloud Keychain / Google Password Manager） プロジェクト・ミーミル | Week 5 27
28. RBAC → ReBAC（認可モデルの進化） 古典: RBAC（ロールベース）: ロール（admin / editor / viewer 等）でアクセス制御 2026: ReBAC（レバック / 関係ベース）: 「誰が何を誰に共有してるか」という関係ベースで権限を決める Notion / GitHub / Slack など SaaS で採用が広がる もう一つの 2026 トレンド: AI エージェントへの委任認可 エージェントに渡す権限を絞った短命トークンの設計が新しい論点 プロジェクト・ミーミル | Week 5 28
29. 面接問題③: 認証と認可 3 段階で質問を一段ずつ上げていく構成: ベース（キーワードレベル）: 「認証と認可の違いを説明してください。HTTP で言うと、それぞれどのステー タスコードに対応しますか？」 深掘り①（実装経験あり）: 「JWT を使って認証してるサービスで、ログアウト機能をどう実装しますか？」 深掘り②（最新動向把握）: 「パスキーや AI エージェントへの委任認可が広がってきました。これらを使う設 計だと、認証認可の何が変わると思いますか？」 プロジェクト・ミーミル | Week 5 29
30. 面接問題③: 良い回答 / 不十分な回答 深掘り①（実装経験）:JWT は発行後に取り消せない仕組み → 有効期限を短く / 取り 消したトークン一覧をサーバー保持 「クライアントで JWT 削除」 （コピー済みなら無効化できない） 深掘り②（最新動向）:パスキーでパスワード自体が消える → フィッシング耐性が上が る AI エージェントには 権限を絞った短命トークン（短い期限付き）を渡す設計 「変わらないと思います」 （現状認識が古い） プロジェクト・ミーミル | Week 5 30
31. プチテスト 時間外で各自取り組み（次回まで） プロジェクト・ミーミル | Week 5 31
32. まとめ・次回予告 今日のポイント: カーネル・スレッド: M:N と goroutine コンテナ: namespaces / cgroups で隔離 セキュリティ: XSS / CSRF / SQLi、認証 vs 認可 次回 Week 6（2 週分）: 設計論 + チーム開発 + インフラ全体 + API 冪等性 プロジェクト・ミーミル | Week 5 32
33. 自習リソース リソース 内容 Linuxのしくみ 増補改訂版 10-11章 仮想化・コンテナ機能の詳細 Docker 公式ドキュメント Docker / docker compose の基本 OWASP Top 10 Web 攻撃手法の定番リスト JWT.io JWT のデバッガー（実物を見る） プロジェクト・ミーミル | Week 5 33