踏み台サーバによるセキュアメンテナンスパターン#

本構成は従来リージョン向けとなります。
東日本/西日本リージョン3ではAZは1つの提供となり、構成変更が必要です。
類似構成として バックLANパターン[東日本/西日本リージョン3向け] を参照ください。

要求事項#

  • インターネットやイントラネット等の外部から、安全にシステムにログインできるようにしたい

対応するデザインパターン概要#

セキュリティを担保するために、メンテナンス等でサービス提供中のWebサーバ等にログインする必要がある場合でも踏み台サーバを経由してログインすることがベストプラクティスです。
これにより、以下のリスクを回避することができます。

  • メンテナンス対象サーバにログインするための複数経路が存在することによる攻撃リスク
  • 何らかの設定変更作業により意図せずセキュリティホールを生み出してしまうリスク

本パターンでは、インターネットやイントラネット等の外部から対象の仮想サーバにログインする際に、ログイン経路が1か所となるような踏み台サーバを用意することでセキュリティを高める構成を紹介します。
本構成の特徴は以下の通りです。

  • メンテナンスに必要な時のみ踏み台サーバを起動 (または復元)
  • メンテナンス対象サーバーにログインする必要があるときのみ、踏み台サーバからのアクセスをセキュリティグループによって許可

Note

セキュリティグループは仮想サーバに対して割り当てと解除が可能です。
下図の例のように、踏み台サーバからのアクセスを許可する SG_Maintenance を、メンテナンスの際にだけ Webサーバに付与する運用が可能です。

構造 (イメージ図)#

以下では、考え方を提示するためもっとも簡略な構成例を記載しています。
その他の構成例としては、その他 で、ネットワーク構成を2階層にした構成例や、マルチAZにした構成例、プロジェクト間接続を使った構成例などを記載しています。

通常時 メンテナンス時
  • 通常時は、踏み台サーバを停止 (または解放) します
  • インターネットからログイン可能なサーバが存在しない状態です
  •                                                                                                                                                                      
  • メンテナンス時に踏み台サーバを起動 (または復元) します
  • 特定のアクセス元からのみ、ログインできるようにします
  • ログインする対象のサーバだけセキュリティグループを付与する運用にすると、さらに安全性が高まります
  • image image

    実装サンプル#

    1. 作業フロー#

    (1) 踏み台サーバ復元#

    踏み台サーバを復元し、ログインできる状態にします。
    復元方法は、仮想サーバの解放/復元 を参照してください。

    (2) セキュリティグループ付与#

    セキュリティグループ "SG_Maintenance" を作成し、webサーバに割り当てます。
    作成方法は、セキュリティグループ "SG_Maintenance" の設定例 を参照してください。
    割り当て方法は、セキュリティグループ "SG_Maintenance" の割り当てと解除 を参照してください。

    (3) メンテナンス作業実施#

    踏み台サーバを経由して、Webサーバにログインします。
    Webサーバにてメンテナンス作業を実施後、Webサーバおよび踏み台サーバからログアウトします。

    (4) セキュリティグループの解除#

    セキュリティグループ "SG_Maintenance" を解除します。
    解除方法は、セキュリティグループ "SG_Maintenance" の割り当てと解除 を参照してください。

    (5) 踏み台サーバ解放#

    踏み台サーバを解放し、ログインできず、コストもかからない状態にします。
    解放方法は、 仮想サーバの解放/復元 を参照してください。

    2. セキュリティグループ "SG_Maintenance" の設定例#

    踏み台サーバから ssh接続を受け付けるセキュリティグループの設定例です。

    本パターンの踏み台サーバは、構造 (イメージ図) のように "SG_Gate" というセキュリティグループが設定されているため、"SG_Gate" から ssh (22/tcp) を受信可とする設定をします。

    ルール 方向 オープン
    ポート
    ポート 接続先 セキュリティグループ
    またはCIDR
    カスタム
    TCPルール
    受信 ポート 22 セキュリティグループ SG_Gate

    このセキュリティグループ "SG_Maintenance" を、Webサーバのメンテナンスの際に割り当て/解除することにより、必要な時だけ Webサーバにログインする運用となります。

    なお、実際のセキュリティの設定にあたっては、上記の設定例以外のセキュリティの要件もあわせて検討してください。

    また、アクセス制御の方式では、セキュリティグループだけではなく、ファイアーウォールも含めてセキュリティ設定を検討してください。

    検討にあたっては、以下のデザインパターンを参照してください。

    デザインパターン名称 説明
    セキュリティグループ活用 セキュリティグループのみでアクセス制御するパターンです。
    セキュリティグループ/ファイアーウォール併用 セキュリティグループおよびファイアーウォールを組み合わせたパターンです。
    機能別セキュリティグループ 機能別にアクセス制限をかけるパターンです。

    3. セキュリティグループ "SG_Maintenance" の割り当てと解除#

    • セキュリティグループ "SG_Maintenance" の割り当て

      • 「コンピュート」⇒「仮想サーバ」と選択した画面で、Webサーバのリンクをクリックします。
        「仮想サーバ詳細」画面で、Webサーバの詳細情報が表示されます。
      • Webサーバの詳細画面の「ポート」一覧で、WebサーバのIPアドレスが表示されている項目の「アクション」メニューから、「セキュリティグループ設定」をクリックします。
      • 「セキュリティグループ設定」画面で、「全てのセキュリティグループ」の中から "SG_Maintenance" をクリックし、「選択」ボタンをクリックします。
        "SG_Maintenance" が、「仮想サーバのセキュリティグループ」に表示されます。
      • 最後に「OK」ボタンをクリックすると、"SG_Maintenance" が Webサーバに付与され、踏み台サーバからログインできる状態になります。
    • セキュリティグループ "SG_Maintenance" の解除

      • 「コンピュート」⇒「仮想サーバ」と選択した画面で、Webサーバのリンクをクリックします。
        「仮想サーバ詳細」画面で、Webサーバの詳細情報が表示されます。

      • Webサーバの詳細画面の「ポート」一覧で、WebサーバのIPアドレスが表示されている行の「アクション」メニューから、「セキュリティグループ設定」をクリックします。

      • 「セキュリティグループ設定」画面で、「仮想サーバのセキュリティグループ」の中から "SG_Maintenance" をクリックし、「解除」ボタンをクリックします。 "SG_Maintenance" が、「全てのセキュリティグループ」に表示されます。

      • 最後に「OK」ボタンをクリックすると、"SG_Maintenance" が Webサーバから解除され、踏み台サーバからログインできない状態になります。

    メリット・効果#

    本パターンを利用して、踏み台サーバを配備した場合のメリット・効果は以下の通りです。

    • システムへのログイン経路を単一化することで、高いセキュリティを実現可能
    • 踏み台サーバの起動/停止作業や、セキュリティグループの付与作業を組み合わせることで、設定ミスで不用意にアクセスされたりすることを無くす等、運用面での安全性の向上が可能

    注意事項#

    • 本パターンは2017年5月時点のFJcloud-O 従来リージョンで動作検証しています。
    • 踏み台サーバを用いた構成は、その他 に記載のように様々な構成を実現できますが、
      FJcloud-O でのネットワーク構成は非常に自由度が高いため、ファイアーウォールやセキュリティグループにて通信の制御は必ず行ってください。

    その他#

    踏み台サーバの構成例について#

    構造 (イメージ図) では、考え方を提示するためもっとも簡略な構成例を記載していますが、 ネットワーク構成を2階層構成にしたり、マルチAZ構成にしたり、プロジェクト間接続を使うことにより、 以下のように様々な構成が可能です。

    ログイン対象のサーバおよび
    踏み台サーバ の配備先
    外部接続する
    仮想ルータ
    ログイン対象のサーバおよび
    踏み台サーバ間のアクセス制御
    同一セグメント構成 1つ セキュリティグループ
    単一のルータで複数セグメント構成 1つ セキュリティグループ
    セキュリティグループ+ファイアーウォール
    マルチAZ構成 2つ セキュリティグループ
    外部接続するルータを複数配備した構成 2つ セキュリティグループ
    セキュリティグループ+ファイアーウォール
    プロジェクト間接続を行った構成の場合 2つ セキュリティグループ
    セキュリティグループ+ファイアーウォール

    1. 単一のルータで複数セグメントの構成とした場合#

    単一のルータで 2階層ネットワーク を構成した場合の構成例です。
    セキュリティの設定で、Webサーバが配備されるインターネットに公開されるセグメントに直接ログインできないようにします。
    小規模でも、ファイアーウォールとセキュリティグループで、アクセス制御を多重で行ってセキュリティを高めています。

    image

    2. マルチAZ構成とした場合#

    マルチAZ接続パターン のように、マルチAZ でネットワークを構成した場合の構成例です。
    下図では、別AZのセグメントをネットワークコネクター経由で接続しています。

    踏み台サーバとログイン対象のサーバとの間のアクセス制御は、ネットワークコネクター経由の場合はセキュリティグループのみとなります。

    image

    なお、ネットワークコネクターを利用したマルチAZ構成では、同一のAZ内でも複数のセグメントを接続可能です。
    要件に応じて、マルチAZ接続パターン の その他 で記載した複数セグメントの例と組み合わせて構成を検討してください。

    3. 外部接続するルータを複数配備した構成の場合#

    複数ルータ外部接続パターン で構成した場合の構成例です。
    外部接続するルータを複数利用することにより、インターネットに公開のセグメントへの入り口の仮想ルータ、および踏み台サーバのセグメントへの入り口となる仮想サーバを、完全に分離しています。

    各々のセグメントの仮想ルータを分けることにより、仮想ルータに対する設定ミス等の削減、および設定ミスによる不用意なアクセスの発生を防止します。

    image

    4. プロジェクト間接続を行った構成の場合#

    プロジェクト間接続による共通サービスパターン で構成した場合の構成例です。
    この例では、3. 外部接続するルータを複数配備した構成の場合 を、複数プロジェクトに拡張しています。
    別のプロジェクト、あるいは、複数のプロジェクトでシステムを構築しているような形態では、それらのシステムに単一のプロジェクトの踏み台サーバからログインする構成が推奨されます。

    なお、プロジェクト間接続を行っている場合は、プロジェクト間でセキュリティグループを共有できないため、セキュリティグループのルールの記載は IPアドレス (CIDR形式) で行う必要があります。

    image