クラウドサービスの導入検討

読み：くらうどさーびすのどうにゅうけんとう　／　英語表記：cloud service adoption

オンプレミスの機器（プロキシサーバなど）からクラウドサービスへ移行するときに、機能や費用だけでなく、通信の経路、ネットワークの設定の変更点、既存のサービスへの影響を事前に洗い出し、トライアルで検証すること。

イマシルちゃんの解説

新しい便利なクラウドサービスを見つけても、「よし、明日から全部これ！」ってすぐ切り替えると、思わぬところで困っちゃうんだ。

通信がどこを通るようになるのか、今の設定のどこを変えないといけないのか、ほかのサービスに影響はないか……。
こういうことを、机の上でしっかり考えてから、まずはお試し期間で確かめる。
午後の問題では、この「導入前に何を考えるべきか」がよく問われるんだよ！

観点	確認すること
機能	必要な機能があるか。既存の機器の機能（ブロックの設定など）を移せるか
通信の経路	導入後、各端末の通信がどこを経由するようになるか。遠回りにならないか
ネットワークの設定	ファイアウォールの許可ルール、端末の設定（プロキシ、証明書、エージェント）の変更点
外部サービスへの影響	送信元のIPアドレスが変わることで、接続を制限している外部のサービスに影響しないか
ログと監査	必要なログが、どこで、どの形で取得できるか
可用性と移行	サービスが止まったときの影響、段階的に移行できるか、元に戻せるか

クラウドのセキュリティサービス（SWGなど）を導入すると、端末からの通信は、いったんインターネット上のサービスを経由してから宛先に向かう。導入前と導入後で、通信の経路を構成図の上でたどり、次の点を確認する。

確認すること	例
送信元のアドレスの変化	宛先から見た送信元が、自社の出口のアドレスから、サービスのアドレスに変わる。送信元のアドレスで接続を制限しているSaaSは、許可するアドレスをサービス側のアドレスに変更する
社内宛ての通信	社内のサーバへの通信まで、インターネット上のサービスを経由させると、遠回りになり、ファイアウォールや回線の負荷、遅延が増える。社内の宛先は直接接続にする
社外の端末からの社内の利用	テレワークのPCから社内のサーバに接続する経路を用意する（リバースプロキシなど）

変更	内容
許可ルールの追加	端末からクラウドサービスへの通信（TCP/443など）を許可する
許可ルールの削除	使わなくなる機器（フォワードプロキシなど）のための許可ルールを削除する。不要なルールを残すと、攻撃の入口になる
端末の設定	エージェントソフトの導入、HTTPSの検査のためのルート証明書のインストール

セキュリティの事故が起きたときに、誰の端末かを特定できるように、ログをつなげて追えるようにしておく。

段階	使うログ
不正な通信の発見	ファイアウォールやSWGの通信ログ（送信元のIPアドレス、時刻）
端末の特定	DHCPのリースログ（その時刻に、そのIPアドレスを使っていた端末）
利用者の特定	認証のログ

複数の機器のログを時系列で突き合わせるため、すべての機器の時刻をNTPで同期しておく。

多くのクラウドサービスには、試用期間がある。机上で検討した内容を、実際の環境で確かめ、業務への影響を見ながら設定（ブロックの基準など）を調整し、移行の手順を固めてから本格的に導入する。

問われ方	答え方のポイント
導入後の通信の経路	構成図の記号を使って、端末から宛先までの順をたどる
追加・削除する許可ルール	送信元、宛先、プロトコルとポート番号を、通信を始める向きで答える
外部のサービスの設定変更	送信元のアドレスが変わることへの対応
直接接続にする利点	経路の短縮による、機器の負荷の軽減、応答時間の短縮