クラウドなら任せてよい？｜責任分界・FW規則・監視の設計

クラウドへ移せば、サーバの更新やアクセス制限も全部任せられるのでしょうか。任せられる範囲はサービスによって違います。まず業務の入口とデータの保存先を描き、誰が何を設定するかを確かめます。

事例：公開Webと社内DBを分ける

C社は公開Webアプリをクラウドの仮想マシンで動かします。利用者は入口のロードバランサへHTTPSで接続し、アプリがDBへ問い合わせます。管理者は管理用経路を使い、DBにはインターネットから直接接続させません。

LBは通信を受けてアプリへ振り分けるロードバランサです。この例では各区間でTLSを使います。ポートを許可するだけでTLSや証明書検証が有効になるわけではありません。

IaaS・PaaS・SaaSで、自社の担当はどう変わる？

責任分界は、事業者が提供する部分と、利用者が設定・管理する部分の境界です。IaaSは仮想マシン等の基盤、PaaSはアプリ実行の基盤、SaaSは完成したアプリ機能をサービスとして使う形です。

実際の境界は契約とサービス仕様で確認します。マネージドDBでも、データを公開する設定や自社の利用者権限が自動的に正しくなるわけではありません。基盤の運用を任せることと、業務データへのアクセスを管理することは別です。

この例はIaaSなので、C社はゲストOSとアプリの更新を管理します。事業者が物理機器を更新しても、C社が導入した脆弱なライブラリまで修正されたとは判断しません。

FW規則は『誰から、どこへ、何を』で書く

FWはファイアウォールで、通信を規則に従って許可・拒否する仕組みです。許可対象は通信方向、送信元、宛先、プロトコル、宛先ポートをそろえて定めます。必要な経路だけを許可し、広すぎる規則を残さないようにします。

DBの規則は『社内だからすべて許可』ではなく、DBへ接続するアプリや管理経路を限定します。アプリが侵害された場合にDBへ到達できる可能性は残るので、DB認証と権限、アプリの入力検証も必要です。

許可規則の識別子、担当者、業務目的、有効期限を残すと、後から不要な例外を削除できます。変更前には管理経路を切断しないか確かめ、検証結果と切戻し手順を用意します。

戻り通信の規則は、いつ必要？

ステートフルな制御は接続状態を追い、許可した通信に対応する応答を扱います。ステートレスな制御は各パケットを個別に規則へ照合します。この違いで、応答側に必要な許可の書き方が変わります。

AWSのセキュリティグループはステートフルで許可規則を使い、ネットワークACLはステートレスで許可・拒否と規則順序を使います。製品名を外した一般的なFWへ、同じ評価方式をそのまま当てはめないようにします。

開始：10.0.10.20:51000 → 10.0.20.30:5432
応答：10.0.20.30:5432 → 10.0.10.20:51000

この通信ではクライアント側が51000番を一時的に使っています。ステートレスな規則なら、応答の宛先は5432番ではなく51000番です。一時ポートの範囲は対象OS等で確認し、例の一つの番号を全接続へ固定しません。

経路が片方向だけ通る場合や、冗長機器で状態が共有されない場合もあります。規則だけでなく、ルーティング、NAT、接続状態を順に追います。

監視ログは、どの問いに答える？

通信の記録だけでは、利用者が何を更新したかまで分からないことがあります。フローログ、LBのアクセスログ、アプリの操作ログ、管理操作の監査ログを組み合わせます。保存内容はサービスと設定で違います。

1. 通信

   送信元・宛先・ポート・許可／拒否から、規則と経路を確認します。本文内容まで含むとは限りません。

2. アプリ

   要求ID、利用者、対象、結果から、業務操作を追います。秘密や不要な個人情報を記録しないようにします。

3. 管理

   誰がいつ規則・権限・保存設定を変えたかを確認します。

4. 時刻

   時刻同期とタイムゾーンをそろえ、同じ要求の記録を対応付けます。

ログを有効にするだけでは、異常を検知したことになりません。検知条件、通知先、担当者、対応期限を決め、拒否通信や規則変更を使った確認で通知が届くか検証します。

ログの閲覧権と削除権は分け、保存先の保護と必要な保持期間を決めます。ログがないことは攻撃がなかった証拠にならず、取得の有無、対象範囲、欠落や遅延を確かめてから判断します。

許可した通信でも、残る危険はある？

443番を許可しても、不正な要求を含むHTTPSは通り得ます。WAFはWeb要求の検査を助けますが、アプリの権限不備をすべて自動で解決するものではありません。暗号化、通信制限、認証・認可、アプリ修正を対応する場所へ置きます。

公開ストレージ、過大なAPI権限、漏えいした鍵はネットワーク境界の外側でも問題になります。サービスごとの公開設定と利用者権限を一覧にし、許可された経路を使う攻撃も含めて点検します。

演習1：自社の更新対象

条件：IaaSの仮想マシンへC社がOSと業務アプリを導入する。

問い：ゲストOSとアプリの更新は誰が管理するか。

解答例：C社が利用者側の管理範囲として確認し、更新する。

根拠：IaaSで事業者が管理する基盤と、利用者が導入したOS・アプリは別である。

誤答の理由：『クラウドなので事業者が全部更新する』では責任分界を確認していない。

演習2：DBへの許可

条件：LB、アプリ、DBがあり、DBはアプリからのみ業務要求を受ける。

問い：DBの業務接続をどの送信元に限定するか。

解答例：業務アプリの送信元に限定する。

根拠：利用者はLBへ接続し、DBへ接続する主体はアプリである。

誤答の理由：『LBからDBへ直接許可』は事例の通信経路と合わない。

演習3：応答側のポート

条件：クライアント51000番からDBの5432番へ接続する。制御はステートレス。

問い：応答パケットの宛先ポートは何番か。

解答例：クライアントの51000番。

根拠：応答では往路の送信元と宛先の組が逆になる。

誤答の理由：『応答も宛先5432番』はサーバの待受ポートとクライアントの一時ポートを混同している。

演習4：規則を変えた人

条件：DBへの接続が急に許可された。通信ログには接続元だけが記録される。

問い：規則変更を行った人を調べるために必要な記録は何か。

解答例：FWやクラウド設定の管理操作を記録する監査ログ。

根拠：通信した主体と設定を変更した主体は別に記録する必要がある。

誤答の理由：『フローログだけで変更者も分かる』はログの対象を超える推測である。

演習5：マネージドサービス

条件：SaaSの共有設定をC社が全員公開に変更した。

問い：提供アプリの保守を任せていれば、この設定も安全か。

解答例：安全とは言えない。自社の共有範囲と利用者権限を確認する必要がある。

根拠：サービス運用と利用者が設定するデータ公開範囲は別の責任である。

誤答の理由：『SaaSなら自社の設定責任はない』は利用者側の管理を見落としている。

演習6：監視の実効性

条件：拒否通信を記録する設定はあるが、アラートが担当者へ届くか未確認である。

問い：運用開始前に追加で確かめることを述べる。

解答例：検知条件に該当する試験通信を使い、通知先と担当者の対応まで確認する。

根拠：記録・検知・通知・対応がつながって初めて運用で利用できる。

誤答の理由：『ログを一年保存する』だけでは通知の欠落を検証できない。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

AWS：責任共有モデル

NIST SP 800-145：クラウドの定義

NIST SP 800-41 Rev.1：FWの方針

AWS：セキュリティグループ

AWS：ネットワークACL

関連テーマを続けて学ぶ

認証・アクセス制御

IP・経路・NAT