「オンプレのネットワーク構成をクラウドへまるっと移行」はお ... - ITpro

全2836文字

　オンプレミスのシステムをクラウド上に移行するとき、移行トラブルを避けるためにオンプレミスのネットワーク構成や設定をそのまま持ち込みたくなるかもしれない。

　だが、ときにそれは最適ではない。クラウド側の仕様に合わず、「期待したほど運用の手間やコストを減らせなかった」となりかねないからだ。米Amazon Web Services（アマゾン・ウェブ・サービス）のサービスを例に、クラウドならではの仕様に潜む落とし穴を見ていこう。

環境別にネットワークをつくる

　まず注意したいのが、オンプレミスのネットワークにおいて、同じセグメントに本番環境や開発環境といった様々な環境のIT資産を混在させている場合だ。そのまま移すと当然、様々な環境のIT資産が同じ仮想ネットワークやサブネットに混在する。

環境別にネットワークを細かく分離

本番環境と開発環境が混在したり、様々な役割のIT資源が同じサブネットに混在したりしているオンプレミスのネットワークをそのままクラウドの仮想ネットワークに移行すると、セキュリティーや保守の面で課題が生じる。仮想ネットワークの特徴を生かして細かく分割して利用するほうが、セキュリティーや保守性、耐障害性を高められる。

[画像のクリックで拡大表示]

　こうしたネットワークはクラウドでも管理しにくい。開発環境を操作しているつもりが誤って本番環境を操作してしまうなど、セキュリティーのリスクも高い。ネクストモードの里見宗律（むねのり）社長は、「オンプレミスではルーターの台数が足りないなどの事情で、環境別にネットワークを組めなかった企業もあるだろう。その場合は移行を機に、クラウドの仕様を生かして設計し直したい」とする。

　具体的にどうすればよいだろうか。クラウドのネットワーク構築に詳しい技術者は「環境別にネットワークを細かく分ける」（アイビーシーの井上周洋コンサル・インテグレーション事業部コンサルティング部シニアコンサルタント）と口をそろえる。

　例えば本番環境と開発環境にそれぞれ仮想ネットワークをつくる。さらに外部と接続する必要性などに応じてIT資産を分類し、サブネットを分ける。そもそもクラウドでは仮想ネットワークなのでこうした構成を比較的容易に設定できる。

　また、AWSの仮想ネットワークは同じリージョン内の複数のアベイラビリティーゾーン（AZ）をまたいで設定できる。各AZにサブネットを設置して同じシステムを用意すれば、一方のAZに障害が発生しても別のAZのシステムで稼働し続けられる。オンプレミスではコストがかさみがちなデータセンターごとの冗長化のハードルも下がる。

2種類のファイアウオール機能

　続いて、クラウドならではの仕様として、仮想サーバーに対するアクセス制御を説明しよう。AWSの仮想ネットワークでは2種類のファイアウオール機能を利用できる。1つはサブネット単位で制御する「ネットワークACL（Access Control List、以下NACL）」、もう1つは仮想サーバー単位で制御する「セキュリティグループ」である。

クラウドにある2種類のファイアウオール

AWSの仮想ネットワーク用のファイアウオール機能には、サブネット単位で制御する「ネットワークACL」と仮想サーバー単位で制御する「セキュリティグループ」がある。他事業者のクラウドサービスもネットワークごと（サービスによって仮想ネットワーク単位とサブネット単位に分かれる）と仮想サーバーごとで制御できるようにしているものが多い。

[画像のクリックで拡大表示]

　NACLはオンプレミスのネットワークで考えると、サブネットの境界に設置するルーターでフィルタリングするのと感覚が似ている。このためクラウドでもNACLを使いたくなるかもしれない。

　だが、AWSに詳しい技術者は「セキュリティグループをメインに使ったほうがよい」と口をそろえる。提供元も同意する。「多くの場合、NACLの利用を推奨していない」（アマゾンウェブサービスジャパンの瀧澤与一パブリックセクター技術統括本部長）。

掲載予定記事

Adblock test (Why?)