CDP:Ondemand Activation パターン
メンテナンス時の一時的な設定変更
目次 |
解決したい課題
システムをセキュアにするための、サーバーに対する外部からのアクセス（インバウンド）は通常、最低限必要なものに制限されている。また、メンテナンスなどで各サーバーへのログインを行う際は、ログイン元を制限するために踏み台サーバー（Bastion）を経由する場合が多い。さらに、外部への情報流出を防ぐために、サーバーからの外部へのアクセス（アウトバウンド）を禁止するケースもある。
サーバーへのインバウンド、アウトバウンドを制限すればセキュリティは高まるが、その半面、メンテナンスが容易ではなくなる。例えば、単純に外部への通信を拒否するような設定を実施すると、OSパッケージのアップデートなどインターネットへアクセスする必要があるメンテナンス作業ができなくなるため、システム構築の際には、必要なセキュリティの確保とメンテナンスの容易性の両方のバランスが求められる。
クラウドでの解決/パターンの説明
クラウドでは仮想サーバーの起動・停止、ファイアウォールの設定変更など、従来であれば人手を介す必要がある設定変更を、API 経由で容易に実施できる。
このため、踏み台サーバーは外部からアクセスする必要があるときのみ、NATはOSパッケージのアップデートなどのメンテンス時だけ起動するような仕組みを作り、セキュリティを高めつつメンテナンス性を上げることができる。同様に、ファイアウォールも任意のタイミングで変更可能なため、通信が必要な場合のみ通信を許可するといった柔軟な使い方が可能となる。
従来はサーバーなどは恒久的に利用し続ける前提であり、一時的に利用するサーバーを一時的に起動停止することは、コストや運用負荷の観点で現実的ではなかった。一方、クラウド上の仮想サーバーは従量課金で利用できるため、必要な時のみ利用することでコスト面でも利点がある。
実装
①踏み台サーバの一時的な起動
踏み台サーバー（Bastion）用のAMIを用意し、必要な時のみEC2を起動して、そこから各サーバーにアクセス（ログイン）できるようにする。
- システムへのアクセス（ログイン）が必要になった場合、踏み台サーバーを起動。
- システムのメンテナンスなどを実施。
- メンテナンス終了時、EC2（踏み台サーバー）の終了/停止を行う。
②NATサーバの一時的な起動
外部への通信が必要な場合に、NAT インスタンスを起動する。
- メンテナンス開始時（インターネットへのアクセスが必要な時）にNATインスタンスを立ち上げる。
- サブネットのルーティングでNATインスタンスの設定を行う。
- メンテナンス終了時、ルーティングからNATインスタンスの設定を削除し、NATインスタンスも停止/削除する。
③セキュリティグループの一時的な設定変更
一時的に許可するセキュリティグループを用意して、必要な時のみ必要なインスタンスに、そのセキュリティグループを適用する。
- 一時的に利用するセキュリティグループを事前に用意。
- システムのメンテナンスなどを実施するときに、そのセキュリティグループをEC2に適用。
- メンテナンス終了時、そのセキュリティグループをEC2から外す。
上記三つの実装を組み合わせて、より高いセキュリティで低コストのシステムを実現できる。
構造
① 踏み台サーバの一時的な起動
② NATサーバの一時的な起動
③ セキュリティグループの一時的な設定変更
利点
- サーバーを起動してないときは、システムにログインする経路やインターネットにつながる経路がないので、システムをよりセキュアに保てる。
- サーバーは利用するときのみ稼働させるので、コスト削減につながる。
- セキュリティグループを適用してないときは、EC2にアクセスする経路がないので、システムをセキュアに保てる。
注意点
- サーバーの停止、ルーティングの変更などを伴うため、オペレーションミスが起こらないようにスクリプトで自動化、もしくはCloudFormationをテンプレート化すると安全である。[関連ブログ 1]
その他
- 社内ワークフローと連携して、メンテナンスの承認が下りたイベントに合わせて、APIで設定変更を自動で実行することも可能。また、セキュリティグループなどを外し忘れる可能性もあるので、毎日定時にセキュリティグループなどの設定を自動で外す仕組みを導入すると、よりセキュリティを高められる。
