[Cloud, Network] hiding a server in the cloud

原文はこちら。
https://blogs.oracle.com/pshuff/entry/hiding_a_server_in_the

---

先日サーバの保護とインターネットから隠すことについて質問がありました。昨日Webサーバとプライベートネットワークで通信し、インターネットから見えなくすることについて説明しました。質問の核心は、コンソールやシェルへのアクセスを隠し、Oracle Cloudの他インスタンスからのアクセスだけを許可できるか、というものです。
確認するために、セキュリティ・ルールとセキュリティ・リストを定義することでサーバへのインバウンドおよびアウトバウンドポートを構成することができます。ここでは、インターネット、サイト、インスタンス間で通信するためのポートを許可します。セキュリティ・リストの詳細は、以下をご覧ください。

Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)
Managing Security Lists
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-C94EF16D-DD88-46D9-B37E-20C2A3F62E6F.htm#OCSUG144

なお、新たにセキュリティ・リストを定義するためにはCompute_Operationsロールに属している必要があります。あなたは、新しいセキュリティのリストを定義することができるようにCompute_Operationsの役割を持っている必要があります。セキュリティ・リストを使って、着信パケットに対しACKを返さずに無視したり、ACK付きで拒否したりすることができます。推奨構成は、応答せずに無視することです。アウトバウンドポリシーを使うと、ACKなしで無視するか、ACK付きでパケットを拒否することができます。アウトバウンドポリシーは、プログラムに外部環境と通信させたり、インスタンスをロックダウンさせたりすることができます。デフォルトでは、アウトバウンドは全て許可、インバウンドは全て拒否するよう設定されています。
セキュリティ・リストを定義すると、セキュリティ・ルールを使ってリストに例外を作成します。セキュリティ・リストに関する詳細情報は以下をご覧ください。

Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)
Managing Security Rules
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-630622EC-160B-4523-88AD-F7B46463A0BE.htm#OCSUG145

セキュリティ・ルールを管理するためには、Compute_Operationsロールに属している必要があります。ルールに対し、名前を付け、特定のポートで通信を有効または無効を定義します。たとえば、defaultPublicSSHAccessは、インターネットからインスタンスへの22/tcpに対する通信を許可するように設定されています。Linuxインスタンスへコンソールとコマンドラインでのログインを許可するデフォルトのセキュリティリストにこれをマッピングします。本日は新たにセキュリティ・リストを作成することにします。このセキュリティ・リストは、ローカルインスタンスがSSHでの通信を許可し、パブリックアクセスを無効にします。ローカルの22/tcpへのルーティングを作成するセキュリティ・ルールを作成します。アクセスを許可するものです。まずセキュリティ・アプリケーションを選択してポートを定義します。今回の例では、22/tcpに対応するSSHを許可したいと思います。その他にも、送信元、送信先を定義する必要があります。セキュリティ・リストやセキュリティIPリストに接続することもできます。セキュリティIPリストでは、インスタンスやインターネット、サイトを送信元、送信先を定義します。画面左側のセキュリティIPリストタブを使って別のオプションを追加することができます。デフォルト定義を見ると、インスタンスが管理ドメイン（AD）に割り当てられているインスタンスにマッピングされていることがわかります。今回の場合、10.196.96.0/19、10.2.0.0/26、10.196.128.0/19にマッピングされています。その理由は、これら3個のプライベートIPアドレスレンジをADでプロビジョニングすることができるからです。インターネットは0.0.0.0/0にマップされています。サイトは10.110.239.128/26、10.110.239.0/26、10.110.239.192/26にマッピングされています。ネットマスクは、サイトとインスタンス定義の間の重要な違いであることに注意してください。
今日は、（下図のインスタンス1）WebServer1を使って、インターネットからのSSHアクセスを無効にします。また、WebServer2（インスタンス2）からのSSHを有効化し、このコンピュータのコンソールやシェルにアクセスできるようにしたいと思います。我々は、効果的にインターネットからのすべてのアクセスからWebServer1を隠し、WebServer2からこのサーバにプロキシログインのみを許可したいと思います。ネットワークトポロジーは以下のようです。

Step 1:

2日前の構成手順を辿り、ComputeインスタンスではHTTPサーバが動作し、ポートが開いており、ファイアウォールが無効化します。このインスタンスをWebServer1と呼ぶことにします。インターネットからのSSH接続を許可するデフォルトセキュリティ・リストを使います。

Step 2:

WebServer2に対してStep 1を実施します。

Step 3:

まずやることは、新たなセキュリティ・リストを定義することです。このセキュリティ・リストではプライベート・ネットワークでのSSHを許可し、パブリック・ネットワークからのSSHを拒否します。このリストをprivateSSHと呼ぶことにします。

Step 4:

22/tcpのセキュリティ・ルールを定義する必要があります。これは、インスタンスから先ほど作成したprivateSSHセキュリティ・リストへの通信を許可するものです。10.x.x.xネットワーク（パブリックネットワークではありません）の22/tcpを使ったSSHを許可しています。

Step 5:

続いて、WebServer1インスタンスのネットワーク・オプションを更新し、privateSSHセキュリティ・リストアイテムを追加し、デフォルトのセキュリティ・リストを削除する必要があります。この変更を実施する前に、いくつか構成が必要です。まず、SSH鍵をデスクトップから~/opc/.ssh へコピーし、WebServer2がWebServer1へのSSH接続ができるようにします。その後、WebServer2にログイン、さらにWebServer2からWebServer1 へのSSHでのログインテストを実施します。現時点でデスクトップからWebServer1へのSSH接続ができています。これは疎通テストなので、opcユーザーで実施することができます。

Step 6:

セキュリティリストprivateSSHを追加し、デフォルトのセキュリティ・リストを削除します。セキュリティ・リストがWebServer1用に正しく構成されていることを確認します。

Step 7:

WebServer2からWebServer1へのSSH接続が可能であること、デスクトップからWebServer1へのインターネット越しの接続はできないことを確認します。この例では、WebServer1へopcユーザーでデスクトップから接続していますが、Step 6を実行した後に再度接続を試してください。接続に失敗するはずです。


まとめると、2個のWebサーバを用意し一方をパブリックインターネットから隠しました。別のWebサーバからシェルにログインできますが、パブリックインターネットからはログインできません。この例ではWebサーバを使いましたが、それは簡単に試すことができるからです。PeopleSoftやJDE、E-Business Suite、Primaveraのようなより複雑なものでも可能です。SSHアクセス不可にすることと同様に、隠されたサービスと公開されたサービス間でのデータベース通信やアイデンティティの通信のためにより多くのポートを開くことができます。
「パブリックインターネットからのサーバを隠すことができるか？」という問いに対する基本的な答えは、Yesです。セキュリティ・リストやセキュリティ・ルール、セキュリティIPリスト、セキュリティ・アプリケーションを使って簡単にサーバを隠すことができます。必要であれば、これらをOrchestrationやCLIスクリプトで記述することができます。このエントリではComputeコンソールからの実現方法を辿りました。また、Computeコンソールを使って様々なアプリケーションのためにカスタマイズする上で必要な情報を入手するためのドキュメントのリンクを提供しました。