クラウドセキュリティ基礎 LinuC102 第11回

LinuC レベル1 102試験対策シリーズの第11回です。前回までで「ホスト1台を守る」セキュリティ ── ファイアウォール、SELinux、暗号化 ── を学びました。今回は視点を広げ、クラウド全体のセキュリティを扱います。責任共有モデル、IAM（誰が何をできるか）、SSH 踏み台構成、セキュリティグループ。クラウドが当たり前になった現場で、設定ミスによる情報漏洩を防ぐための基礎知識です。本記事は VM を使わない座学回です。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
  第4回 ネットワークトラブルシューティングとDNS
  第5回 ユーザ・グループ管理と sudo 設定
  第6回 ジョブスケジューリングと時刻管理
  第7回 ログ管理実践
  第8回 メール配送エージェント(MTA)の基本
  第9回 ファイアウォールと SELinux 入門
  第10回 暗号化によるデータ保護
▶ 第11回 クラウドセキュリティの基礎    ← いまここ
  第12回 オープンソースの文化

この記事で身につくこと

1. クラウドの責任共有モデルを説明できる
2. IAM のユーザー / グループ / ロール / ポリシーの役割を区別できる
3. 最小権限の原則を説明できる
4. SSH 踏み台（Bastion Host）の役割と構成を説明できる
5. セキュリティグループとネットワークACLの違いを理解している

第1章：なぜクラウドのセキュリティを別に学ぶのか

1.1 オンプレミスとクラウドの違い

これまで学んできたファイアウォールや SELinux は、「自分の手元（または社内）にあるサーバ1台」を守る技術でした。クラウドでは前提が変わります。

• 物理を持たない：サーバの実体はクラウド事業者のデータセンターにある。自分でラックに鍵をかけることはできない
• すべて API で操作できる：サーバ作成・削除・ネットワーク設定・権限変更まで、すべてがソフトウェアから操作可能。便利な反面、設定ミス1つが即座に全世界へ影響しうる
• 規模が大きい：数百〜数千のリソースを少人数で扱う。手作業のチェックには限界がある

1.2 設定ミスが最大のリスク

クラウドの情報漏洩事故の多くは、高度なハッキングではなく 「設定ミス」が原因です。「ストレージを誤って全世界公開にした」「権限を広く付けすぎた」「不要なポートを開けっ放しにした」。第9回で学んだ「最小公開の原則」、第10回の「鍵の管理」が、クラウドではさらに重要になります。

誰のためにクラウドセキュリティを学ぶのか ── それは、クラウドを使う以上、避けて通れない「自分の責任範囲」を正しく理解するためです。次章の「責任共有モデル」がその出発点になります。

第2章：責任共有モデル

2.1 「クラウドだから安全」は誤解

「クラウドを使えばセキュリティは事業者がやってくれる」── これは よくある誤解です。実際には、セキュリティの責任は クラウド事業者とユーザーの間で分担されています。この分担の考え方を 責任共有モデル（Shared Responsibility Model）と呼びます。

担当	責任範囲	具体例
クラウド事業者 （”of the cloud”）	クラウドそのものを動かす基盤	データセンターの物理セキュリティ、サーバハードウェア、ハイパーバイザ、基盤ネットワーク
ユーザー （”in the cloud”）	クラウドの上で自分が構築・運用するもの	OS のパッチ適用、アプリケーション、データの暗号化、IAM 設定、ネットワーク設定、ファイアウォール

覚え方は 「クラウド事業者は『クラウドそのもの（of the cloud）』を、ユーザーは『クラウドの中（in the cloud）』を守る」です。OS のパッチ適用やデータ保護は、クラウドを使っていても ユーザーの責任です。

2.2 サービス種別で分界点が動く

責任の分界点は、利用するサービスの種別によって変わります。

種別	例	ユーザーの責任範囲
IaaS	仮想マシン（EC2 等）	広い（OS から上はすべて）
PaaS	マネージドDB、アプリ実行基盤	中（アプリとデータ、設定）
SaaS	完成したアプリ（メール、CRM 等）	狭い（主にデータとアカウント管理）

仮想マシン（IaaS）を借りるなら、OS の更新もファイアウォールもユーザーの仕事です。SaaS なら事業者の責任範囲が広がりますが、それでも「アカウント管理」「データの扱い」はユーザーに残ります。

第3章：IAM ── 誰が何をできるか

3.1 IAM の4要素

IAM（Identity and Access Management、アイデンティティとアクセスの管理）は、クラウドにおける「誰が、何を、どうできるか」を制御する仕組みです。第5回で Linux のユーザ・グループ・sudo を学びましたが、IAM はそのクラウド版と考えると理解しやすくなります。IAM は4つの要素で構成されます。

要素	意味	Linux でのアナロジー
ユーザー	人や外部システムに対応する恒久的なID	/etc/passwd のユーザ
グループ	ユーザーをまとめて権限を付与する単位	/etc/group のグループ
ロール	一時的に引き受ける権限のセット	sudo での一時的な権限昇格に近い
ポリシー	何を許可/拒否するかを定義した文書	sudoers のルール

3.2 ユーザーとグループ

ユーザーは、人（社員）や外部システムに対応する恒久的なIDです。グループは、ユーザーをまとめて権限を付与する単位 ── 「開発チーム」「運用チーム」のようにまとめ、グループにポリシーを付ければ、所属ユーザー全員に同じ権限が及びます。第5回の Linux グループとまったく同じ発想です。

3.3 ロール ── 一時的に引き受ける権限

ロールは、IAM の中でも特に重要かつ、最初は理解しにくい概念です。ロールは「誰のものでもない権限のセット」で、必要なときに一時的に 引き受ける（AssumeRole）ものです。

典型的な使い方は 仮想マシンやプログラムへの権限付与です。たとえば「EC2 インスタンス上のアプリが、クラウドストレージにファイルを保存したい」とき ──

• 悪い方法：アクセスキー（≒パスワード）をインスタンス内のファイルやコードに書き込む。鍵が漏れたら終わり（第10回のヒヤリハットと同じ構図）
• 良い方法：インスタンスに ロールを付与する。アプリはロールを引き受けて、一時的な権限で動く。鍵をどこにも保存しない

ロールで渡される権限は一時的（自動で期限切れ・更新）なので、恒久的なアクセスキーより安全です。

3.4 ポリシー ── 許可と拒否のルール

ポリシーは「何を許可（または拒否）するか」を定義した文書で、通常 JSON 形式で書かれます。ユーザー・グループ・ロールに ポリシーを紐付けることで権限が決まります。ポリシーの中核は3要素です。

• Effect：Allow（許可）か Deny（拒否）か
• Action：何の操作か（例：ストレージの読み取り、インスタンスの起動）
• Resource：どの対象に対してか

「このグループは、この特定のストレージの読み取りだけ Allow」のように、操作と対象を絞って書くのがポリシー設計の基本です。第5回の sudoers の who where=(as_who) what と発想は同じ ── 「誰が・何に・何を」を明示します。

第4章：最小権限の原則とベストプラクティス

4.1 最小権限の原則

最小権限の原則（Least Privilege）とは、「必要な権限を、必要な対象に、必要な期間だけ与える」という考え方です。第9回の「最小公開の原則」（必要なポートだけ開ける）の、権限版だと考えてください。

「とりあえず全権限（管理者権限）を付けておけば動く」は、最も危険な発想です。そのユーザーやプログラムが乗っ取られたとき、攻撃者にも全権限が渡ってしまいます。権限は「足りなければ後で足す」方向で、狭く始めます。

4.2 IAM のベストプラクティス

• ルートユーザー（最上位アカウント）を日常利用しない：契約時に作られる最上位アカウントは、初期設定後は封印する。日常作業は権限を絞った IAM ユーザーで行う
• MFA（多要素認証）を有効にする：特にルートユーザーと特権ユーザーには必須。パスワードが漏れても、もう1要素で守られる
• アクセスキーをコードに書かない：第10回のヒヤリハット（秘密鍵を GitHub に公開）と同じ。キーはハードコードせず、定期的にローテーションする
• プログラムにはロールを使う：EC2 等にはアクセスキーを置かず、ロールで一時的な権限を渡す
• 操作を監査ログに残す：「誰が、いつ、何をしたか」をクラウドの監査ログサービス（AWS なら CloudTrail）で記録する。第7回のログ管理のクラウド版

第5章：公開鍵管理と SSH 踏み台

5.1 クラウドでの SSH 公開鍵

第10回で学んだ SSH 鍵認証は、クラウドでもそのまま使われます。仮想マシン（EC2 等）を作成するとき、キーペアを指定します。

• 公開鍵：インスタンス作成時に登録され、~/.ssh/authorized_keys に自動配置される
• 秘密鍵：ユーザーがダウンロードして保管する。これを使って SSH ログインする

第10回のヒヤリハットのとおり、この秘密鍵を漏らすとインスタンスへの侵入を許します。クラウドでも「秘密鍵は厳重に守る・漏れたら失効＋ローテーション」は変わりません。

5.2 SSH 踏み台（Bastion Host）

クラウドのネットワークは、通常 パブリックサブネット（インターネットから到達可能）と プライベートサブネット（インターネットから直接は到達不可）に分けます。データベースやアプリのサーバは、安全のためプライベートサブネットに置きます。

では、プライベートサブネットのサーバに SSH で入りたいときどうするか。ここで SSH 踏み台（Bastion Host、要塞ホスト）が登場します。

[管理者] --SSH--> [踏み台 / パブリックサブネット] --SSH--> [DBサーバ / プライベートサブネット]
                                                       --SSH--> [アプリサーバ / プライベートサブネット]

踏み台は パブリックサブネットに置く、SSH の入口専用サーバです。管理者はまず踏み台にログインし、そこを経由してプライベートサブネットの各サーバに入ります。

5.3 踏み台の利点

• SSH の入口が1点に集約される：インターネットに SSH を晒すのは踏み台1台だけ。攻撃面が小さい
• 監査が楽：「誰がいつログインしたか」を踏み台のログだけ見れば把握できる
• パッチ管理が楽：守りを固めるべきサーバが1台に絞られる

第10回で学んだ ssh -J（ProxyJump）を使うと、踏み台を経由した多段接続を1コマンドで書けます。

$ ssh -J developer@踏み台のIP developer@DBサーバのプライベートIP

近年は、踏み台サーバ自体を運用しない 「踏み台レス」のアプローチ（AWS の SSM Session Manager 等、SSH ポートを開けずにブラウザや CLI からシェルに入る方式）も広がっています。踏み台すら攻撃面になりうるため、「入口を持たない」設計が進んでいます。

第6章：セキュリティグループとネットワークACL

6.1 クラウドの2つのファイアウォール

クラウドのネットワークには、2種類のファイアウォール機能があります（AWS の用語で説明します）。

項目	セキュリティグループ	ネットワークACL
適用単位	インスタンス単位	サブネット単位
状態	ステートフル（戻りの通信を自動許可）	ステートレス（戻りも明示的に許可が必要）
ルール	許可ルールのみ	許可・拒否の両方
役割	各サーバの守り	サブネット全体の守り

セキュリティグループは「インスタンスに付けるファイアウォール」で、第9回の firewalld / ufw（ホストファイアウォール）に近い役割です。ステートフル＝行きの通信を許可すれば、戻りの通信は自動的に許可されます。

ネットワークACLは「サブネット全体に付けるファイアウォール」で、ステートレス＝行きと戻りを別々に許可する必要があります。

6.2 三層のファイアウォール

第9回で「ネットワークFW（境界）とホストFW（各サーバ）の二重防御」を学びました。クラウドではこれが 三層になります。

• ネットワークACL：サブネットの境界
• セキュリティグループ：インスタンスの入口
• ホストファイアウォール（firewalld / ufw）：OS レベル

どの層でも考え方は同じ ── 必要な通信だけ許可する。「SSH（22番）を 0.0.0.0/0（全インターネット）に開放」は、第8回のオープンリレーと同じ「楽だから全部許可」の発想で、絶対に避けます。SSH を開けるなら、せめて自社の IP レンジに限定するか、踏み台＋SSM に寄せます。

第7章：Secrets 管理

パスワード、API キー、データベースの接続情報、証明書 ── こうした 機密情報（Secrets）を、ソースコードや設定ファイルに直接書くのは危険です（第10回ヒヤリハットの構図）。クラウドには、機密情報を安全に管理するサービスがあります。

仕組み	役割
Secrets Manager / Parameter Store	パスワードや API キーを集中管理。アプリは実行時に取得（コードに書かない）
KMS（Key Management Service）	暗号鍵の生成・管理。データの暗号化に使う鍵を安全に保管
Cloud HSM	暗号鍵を専用ハードウェア（HSM）で管理する。最も高い保護レベル

原則は 「機密情報はコードに書かず、専用サービスから実行時に取得する」。そして取得する権限は、第3章のロールで渡します。

第8章：現場での使いどころ

現場での使いどころ

• クラウド移行プロジェクトの IAM 設計：オンプレのサーバをクラウドに移すとき、まず「誰が何をできるか」を IAM で設計する。チームごとにグループを作り、最小権限のポリシーを割り当てる
• IaC（Infrastructure as Code）でのセキュリティ実装：Terraform や CloudFormation でインフラをコード化する際、セキュリティグループや IAM ポリシーもコードで管理する。レビューと再現性が得られる
• 運用アクセスの設計：本番サーバへの SSH を、踏み台または SSM に集約する。直接 SSH できるサーバを作らない
• 設定ミスの自動検知：「公開してはいけないストレージが公開されていないか」を、設定監査サービス（AWS Config、Security Hub 等）で自動チェックする
• 監査対応：CloudTrail 等の操作ログを長期保管し、インシデント時や監査時に「誰が何をしたか」を追えるようにする

第9章：ヒヤリハット

第10章：考えてみよう

本記事は座学回のため、手を動かす代わりに次の3つを「考える・調べる」演習として用意しました。紙やエディタに書き出してみてください。

演習1：責任共有モデルを整理する

次の項目について、「クラウド事業者の責任」か「ユーザーの責任」かを分類してください（IaaS の仮想マシンを借りた場合）。

• データセンターの入退室管理
• ゲスト OS のセキュリティパッチ適用
• 物理サーバの故障対応
• アプリケーションが扱うデータの暗号化
• セキュリティグループ（ファイアウォール）の設定

（解答の方針：物理・基盤は事業者、OS から上はユーザー。データセンター入退室と物理故障は事業者、それ以外の3つはユーザー）

演習2：IAM ポリシーを読む

次のような構造の IAM ポリシー（簡略表記）があります。何を許可しているか説明してください。

Effect:   Allow
Action:   ストレージの「読み取り」
Resource: 特定のバケット "project-logs" のみ

続いて考えてください ── このポリシーは「書き込み」も「削除」も許可していません。これが最小権限の原則に沿っているかどうかを判断してください。（方針：ログを読むだけの用途なら、読み取りのみは適切な最小権限。書き込み・削除を与えないのは正しい設計）

演習3：踏み台構成を図に描く

次の要素を使って、ネットワーク構成図を自分で描いてみてください。

• パブリックサブネット（踏み台サーバを配置）
• プライベートサブネット（アプリサーバと DB サーバを配置）
• 管理者の PC からの SSH 接続経路

描けたら、管理者の PC から DB サーバへ接続する ssh -J のコマンドを書いてみてください。「なぜ DB サーバを直接インターネットに公開しないのか」も言葉で説明できれば理解は十分です。

各クラウド事業者は、責任共有モデルや IAM ベストプラクティスの公式ドキュメントを公開しています。AWS / Azure / GCP のうち、自分が使う（使う予定の）事業者の公式セキュリティドキュメントに一度目を通しておくと、現場での理解が早くなります。

理解度チェック

次の5問を ○×で答えてください。解答は記事末尾にあります。

1. 責任共有モデルでは、IaaS の仮想マシンを使う場合、ゲスト OS のパッチ適用はクラウド事業者の責任である。
2. IAM のロールは、EC2 インスタンスなどに付与して、一時的な権限を引き受けさせるために使える。
3. 最小権限の原則とは、トラブルを避けるため最初から広めの権限を付けておく考え方である。
4. SSH 踏み台（Bastion Host）は、プライベートサブネットのサーバへ入るための、パブリックサブネットに置く入口専用サーバである。
5. セキュリティグループはステートフルで、行きの通信を許可すれば戻りの通信は自動的に許可される。

解答

1. ×（ゲスト OS のパッチ適用はユーザーの責任。事業者の責任は物理・基盤まで）
2. ○（ロールはインスタンスやプログラムに付与し、アクセスキー埋め込みを避ける正しい方法）
3. ×（最小権限は「必要な権限だけを与える」考え方。広めに付けるのは逆で危険）
4. ○（踏み台はパブリックに置く SSH 入口専用サーバ。プライベートのサーバへは踏み台経由）
5. ○（セキュリティグループはステートフル。戻り通信は自動許可。ネットワークACL はステートレス）

次回予告

次回（第12回）は、シリーズ最終回 「オープンソースの文化 — 主要ライセンス（GPL/MIT/Apache）とコミュニティ」 です。私たちが日々使う Linux も AlmaLinux も Ubuntu も、すべてオープンソースソフトウェア（OSS）です。主要ライセンスの違い、コピーレフトの考え方、OSS コミュニティへの関わり方を学び、LinuC 102 シリーズを締めくくります。

LinuC 102 試験対策シリーズ（全12回）

1. シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
2. Bashスクリプト入門：if/for/関数で書く現場の自動化スクリプト
3. ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
4. ネットワークトラブルシューティングとDNSクライアント設定
5. ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
6. ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
7. ログ管理実践：journalctl と rsyslog の使い分け
8. メール配送エージェント(MTA)の基本：postfix の動作確認
9. ファイアウォール（firewalld / ufw）と SELinux 入門
10. 暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
11. クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
12. オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ