https://blogs.oracle.com/pshuff/entry/networking_102_part_2
昨日はOracle CloudのLinuxインスタンス上でApache HTTP Serverを起動するところを見ていきました。セキュリティルール、セキュリティリストを作成し、実行中のインスタンスにセキュリティリストを関連付け、OSのファイアウォールを構成する必要がありました。私たちは、城の防衛戦略を取って、OS上のファイアウォールをオフにしました。これは、Linuxインスタンスに対する外部のクラウドファイアウォールが十分よいと信頼しているということです。今日はその仮定をやめて、同じComputeゾーンに2台目のサーバーを作成し、2つのサーバー間での安全な通信を設定することにします。この考えは、我々は、ショッピングカートのバックエンドとしてデータベースサーバーがある場合、パブリックアクセスからデータベースを隠したいというものです。クレジットカード情報、顧客住所や電話番号を安全に保存できるようにしたいのです。パブリックインターネットに1521/tcpを公開するのではなく、Web Application Serverだけを公開したいのです。そして、クラウドインスタンスをセキュアに保ち、誰からもハッキングされないようにしたいのです。
このセキュリティレベルを達成するためには、再度ネットワーク図を確認し、パブリックインターネットに接するパブリックインターフェースではなく、プライベートネットワークインターフェースで通信できることを理解します。やりたいことは、インスタンス1のネットワーク構成をインスタンス2からのトラフィックだけを受け入れるように変更し、インスタンス2をパブリックインターネットに公開することです。構成、テストが簡単なので、上記の検証をApache HTTP Serverを使って実施します。
Step 1:
昨日の構成手順を辿り、Apache HTTP Serverを持つ1個のComputeインスタンスを構成し、ポートを開け、ファイアウォールを無効化します。これからの手順でこのセキュリティ上の問題を解決し、これから作成する2番目のインスタンスだけがアクセスできるようにします。Step 2:
2個目のOracle Linuxインスタンスを同じComputeクラウドで作成します（［インスタンスの作成］でOracle Linux 6.6を選択し、デフォルト構成を受け入れます）。数分後に2個目のLinuxインスタンスができあがります。最初のインスタンスのスナップショットを作成し、この最初のインスタンスをベースにして新規インスタンスを作成することもできます。インストール手順がより複雑な場合にはこの方法を使うといくつかの手順を省略できますが、これは別の日にやることにしましょう。今日はインスタンス用に80/tcpと22/tcpを開けたセキュリティリスト（名前はWebServer）を持つOracle Linux 6.6インスタンスをプロビジョニングします。その他は全てデフォルトの設定を受け入れます。
Step 3:
パブリックIPアドレスをComputeコンソールから入手し、MacでsshもしくはWindowsでputtyを使って、opcユーザでインスタンスにログインします。ログイン後、WebServer1からWebページを読むことができるよう、wgetをパッケージとしてインストールします。
Step 4:
パブリックIPアドレスおよびプライベートIPアドレスを使ってindex.htmlを取得し、WebServer1からWebページを読むことができます。これらのIPアドレスはComputeコンソールで知ることができます。
Step 5:
プライベートIPアドレスでページを読むことができたので、WebServer1からのパブリックIPアドレスでのアクセスを無効化し、10.196ネットワークで通信することができます（プライベートIPアドレスを使った通信）。これはWebServerのセキュリティリストを変更し、デフォルトの設定に戻すことで実現します。セキュリティリストにdefautlを追加し、WebServerというセキュリティリストを削除します。
Step 6:
再度HTTP Serverへのアクセスでインターフェースのテストを実施します。パブリックIPアドレス、プライベートIPアドレスともタイムアウトが発生するでしょう。10.196ネットワークからの80/tcpへのアクセスを許可する新規セキュリティリストを作成する必要があります。
Step 7:
10.196. のネットワークからの80/tcpへのアクセスを許可する新規セキュリティリストを定義する必要があります。これはComputeコンソールの［ネットワーク］タブで新しいセキュリティリストを定義することで実現します。このセキュリティリストをprivateHttpと呼ぶことにします。定義が完了したら、プライベートネットワーク（パブリックネットワークではありません）での80/tcpへのアクセスが許可されます。privateWebServerのためのセキュリティルールを作成し、ローカルインスタンスへの80/tcpを使ったアクセスを許可するようにします。定義完了後、WebServer1インスタンスのセキュリティリストにprivateHttpを追加する必要があります。
Step 7a
privateHttp をセキュリティリストに追加します。
Step 7b
privateWebServerをセキュリティルールに追加します。
Step 7c
セキュリティリストをインスタンスに関連付けます。Step 8:
プライベートネットワークでの接続が可能で、パブリックネットワークでの接続ができないことを確認します。
ここまでで、新規Computeインスタンスを作成し、2個のComputeインスタンスのネットワーク構成を変更しました。目的はApache HTTP Serverでパブリックインターネットからのアクセスに対応するよう、WebServer2インスタンスをセットアップすることでした。。昨日これを実施したのでこれらの手順を再度実施する必要はなかったことを覚えておいてください。WebServer2がWebServer1とプライベートネットワークで会話でき、パブリックインターネットからのWebServer1へのアクセスをできなくしたかったのです。一例としてApache HTTP Serverを使ったのは構成が簡単だからです。この作業はIdentity Server、Database、ファイルサーバ、その他のサービスで実施することができますが、大きな違いは、通信のためのポート、そしてセキュリティリスト、セキュリティルールの作成です。E-Business SuiteやJD Edwardsを稼働させることを考えると、パブリックインターネットに対し、データベースの1521/tcpを公開せず、HTTP Serverを公開したいのです。ERPデータベースを別のサーバで稼働している場合、運転免許証番号、クレジットカード番号、機密情報をパブリックネットワークに公開せず、ERPのロジックを実行しているWebLogic Serverとのセキュアな通信が必要です。この例で考え方を理解し、より複雑なシステムをパブリッククラウドにセキュアに展開できるようになることを願っております。ただ重要なこととして、iptablesの問題を解決しておらず、LinuxインスタンスWebServer1のファイアウォールを停止していることにご注意ください。これはベストプラクティスではありませんが、宿題として残しておきます。
0 件のコメント:
コメントを投稿