2016年9月19日

[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コンソールを使って様々なアプリケーションのためにカスタマイズする上で必要な情報を入手するためのドキュメントのリンクを提供しました。

2016年9月16日

[Cloud, Network] Networking 102 - part 2

原文はこちら。
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のファイアウォールを停止していることにご注意ください。これはベストプラクティスではありませんが、宿題として残しておきます。

2016年9月15日

[Cloud, Network] Networking 102

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

今週は基本的なネットワークのチュートリアルを進めていきます。まずは簡単なネットワーク設定を理解することが重要です。そうすれば、より複雑なネットワーク設定を実施することができます。Oracle Linuxインスタンスを展開し、Apache HTTP Serverをインストールし、80/tcpを公開するところから始めます。これは簡単な作業ですが、自分のインスタンスのIPアドレスを見つける方法、OSやComputeクラウドコンソールでポートを開ける方法、デスクトップや続けて作成する2個目のインスタンスからこのインスタンスに接続する方法を理解する上で有効な作業です。この後、2個のOracle Linuxインスタンスを作成し、Apache HTTP Serverを一方のインスタンスに構成します。ただし、そのインスタンスのみがクラウドの他のインスタンスと通信できるようにします。

Step 1: 

Oracle Computeコンソールを開き、インスタンスを作成します(今回はOracle Linux 6.6のインスタンスを作成)。特別な設定をせずにデフォルトの設定を受け入れます。このサーバインスタンスをWebServer1と呼ぶことにします。SSH接続できるようにデフォルトネットワーク接続を設定します。

数分後、22/tcpが開いているLinuxインスタンスが立ち上がり、SSHでサーバに接続することができます。Apache HTTP Serverはインストールされておらず、80/tcpはOSおよびクラウドネットワークインターフェースでロックダウンされています。

Step 2: 

SSHでインスタンスに接続し、コマンドラインでアクセスできることを確認します。opcユーザーとして接続し、rootとしてコマンドを実行します。この例では、Mac OSのターミナルでSSHコマンドを使って実施しています。Windowsであればputtyを使って接続を作成することが簡単にできるはずです。


Step 3: 

Linuxインスタンスにyumを使ってApache HTTP Serverをインストールします。ソフトウェアをapache.orgからダウンロードし、インストールすることは簡単にできたでしょうが、yumを使うと、1ステップで迅速かつ簡単にインストールし構成することができます。sudoコマンドがoracleとしてログインしていると使えないため、前のステップでopcユーザーとしてログインしていることを確認しておく必要があります。このyumコマンドを初めて実行する場合、様々なカーネルバージョンのためのマニフェスト全てをダウンロードし、依存性をチェックする必要があるため、少々時間がかかります。httpdパッケージには依存性はあまりありませんので、インストールは比較的クリーンです。マニフェストのダウンロードに時間はかかりますが、実際のインストールはそれほど時間がかからないはずです。


Step 4: 

index.htmlを編集し、サービスを起動して実行するためにApache HTTP Serverを構成します。注意いただきたいのは、この状態では自身のコンピュータ(Linuxインスタンス)以外でサービスを見ることができない、ということです。その理由は、クライアントからのリクエストをOSにまで通すためには、OS、クラウドサービスで80/tcpを有効化する必要があるからです。


Step 5: 

クラウドサービスを構成し、パブリックインターネットから作成したインスタンスへの通信を可能にするために80/tcpを開きます。これはComputeコンソールの[ネットワーク]タブをクリックし、新たにセキュリティ・リストを作成して実現します。この例では、通過させるプロトコルとしてhttpとsshを含む新しいリストを作成しています。まず、セキュリティ・リストを作成します。このリストをWebServerと呼ぶことにします。


Step 6: 

先ほど作成したセキュリティ・リストのセキュリティ・ルールとして80/tcpを構成します。httpとsshのルールを作成します。その後、新しいルールが作成されたことを確認します。Linuxインスタンスは現時点ではデフォルト・ルールに関連付けられていることにご注意ください。この次のステップで変更します。


Step 7: 

Linuxインスタンスと新しいルールを関連付けます。これは[インスタンス]タブに移動して[インスタンスの表示]をクリックして進めていきます。どのセキュリティ・リストをこのインスタンスに関連付けるのかを確認し、変更したいと思います。最初はsshのみを含むデフォルトリストに紐付いています。WebServerリストを追加し、デフォルトリストを削除したいのです。最終的にはリストにはsshとhttpを有効にしたWebServerリストのみが含まれるようにします。Webサーバのメンテナンスの利便性を考慮しつつ、デフォルトルールやデフォルトリストを使う別のインスタンスへ影響を与えないようにしたいならばhttpsやsftpを簡単に追加することができます。

Step 8:

ここでOSレベルでポートを開きます。これはSELinuxインターフェースとiptablesインターフェースを変更することによって実施します。サーバの80/tcpへのインバウンドトラフィックを許可したいので、これらのサービスを無効化するか、iptablesルールを追加し、80/tcpへのトラフィックを全て許可することができます。下図のように、SELinuxやiptablesをを止めて全てのファイアウォールルールを無効化することもできますが、実際にはこの設定は推奨されません。その理由は、もしこのマシンもしくはこのインスタンスが稼働しているサーバと同じラックにある別のマシンで、他のポートが開いている場合、全てのポートが開いていて、攻撃に対してOSを脆弱な状態にしてしまうためです。SELinuxやiptablesを無効化する動画を確認したり、チュートリアルのWebページで説明されているコマンドを実行したりすることができます。
Disable Firewall and SELinux Oracle Linux 6 
http://sa-oracle.snapdedo.com/2012/05/disable-firewall-and-selinux-oracle.html 
重要なのはSELINUX=disabledと設定し、iptablesサービスを停止することです。


Step 9: 

変更をテストするために、ブラウザを開き、Apache HTTP Serverに接続します。シンプルなWebクライアントを使ってindex.htmlファイルを取得することもできるはずです。Webページに ”I am here!” というメッセージが表示されているはずです。再度言いますが、これは安全な方法ではありません。本当であれば、iptablesをカスタマイズして、80/tcpのトラフィックを許可し、ssh以外のトラフィックを全て拒否したいのです。

まとめると、Linuxサーバを構成し、Apache HTTP Serverをインストールし、クラウドコンソールとOSレベルでネットワークル―ルを構成し、パブリックインターネットからこのComputeインスタンスへのトラフィックを許可しました。クラウドインターフェースで80/tcpと22/tcp以外の全てのトラフィックをブロックしています。これは拙いプラクティスではあるにせよ、インスタンスのOSレベルのファイアウォールを無効化し、インバウンドトラフィックを全て許可して、クラウドインスタンスをファイアウォールとして利用しています。データセンター内の他のComputeサービスがこれらの開いているポートにアクセスできるため、これはよい方法ではありません。明日、この部分について深掘りし、OSレベルのファイアウォールを再度有効にして、適切に構成していきます。また、データセンター内のサーバ間通信についても、パブリックアクセスからサービスを隠しつつ、パブリックインターネットに面するフロントエンド・サーバが安全にサービスにアクセスできるようにします。

[Cloud, Integration] REST API Now Available for Oracle Real-Time Integration Business Insight

原文はこちら。
https://blogs.oracle.com/integration/entry/rest_api_now_available_in

2016年初頭に、Oracle SOA Cloud ServiceのIntegration Analyticsというサービスタイプがリリースされました。Integration Analyticsというサービスタイプには、Oracle Real-Time Integration Business Insightという、お客様がビジネスマイルストンを追跡し、リアルタイムのメトリックをアプリケーションのコードを変更せずに収集することができる機能が含まれています。Oracle CloudのInsightについての詳細は以下のリンクからどうぞ。
Oracle SOA Cloud Service - Integration Analytics
http://docs.oracle.com/cloud/latest/soacs_gs/index_analytics.html 
オンプレミスのInsightとの違いについては以下のリンクからどうぞ。
Oracle® Cloud Understanding Oracle Real-Time Integration Business Insight Release 12c (12.2.1)
Overview
http://docs.oracle.com/cloud/latest/soa122100/INCON/GUID-E4EB6AC9-EB02-4A8E-AC62-A3E5D4E97742.htm#INCON-GUID-E4EB6AC9-EB02-4A8E-AC62-A3E5D4E97742
最新のSOACSリリースでは、新たなREST APIが発表されました。これを使うとビジネスイベントをInsightに発行することができます。
REST API for Oracle Real-Time Integration Business Insight
http://docs.oracle.com/cloud/latest/soa122100/INAPI/index.html 
この新機能を使うと、ヘテロなカスタムアプリケーション統合をInsightモデルとして含めることができるので、劇的に基盤の力を拡大することができます。カスタムのNode.jsサービスからEJBやオンプレミスのレガシーサービスに至るまでの任意のインテグレーション・コンポーネントが、ビジネスイベントをInsightに投げることができます。必要なのは、シンプルなREST API呼び出しが可能であることです。
Real-Time Integration Business Insightの魔法の重要な部分は、コードを修正しなくてもデプロイされたSOAやService Busアプリケーションからメトリックを展開できるところにあります。マイルストンやメトリックを定義し、これらのモデルをアプリケーション・コンポーネントにマッピングすれば、Insightユーザーがビジネス・パフォーマンスをリアルタイムに追跡することができます。とはいえ、多くの場合、本当にEnd-to-Endのビジネス・マイルストンを達成しようとすれば、プロプライエタリなコンポーネントやOraleコンポーネント以外のものを含めるようにInsightモデルを拡張する必要があります。
Oracle Real-Time Integration Business Insight Event API
REST Event APIは、お客様はInsightに対して求めていた柔軟性を提供します。このAPIを使えば、一つのマイルストンを対象にする一つのイベントだけでなくメトリック(インジケータ)もInsightに送信することができます。イベントをInsightが受信したら、他のアプリケーションから受信したビジネスイベントと関連付け、非同期で処理します。物事をさらに容易にするために、Insightは、アプリケーション開発者に対しマニフェストを提示して、特定のマイルストーンをパスしたとマークすることができるようにするために配信が必要なJSONペイロードを正確に示すようにしています。
Insight API Details Manifest

このInsight APIは、モデル、マイルストン、インジケータ、ダッシュボードのような追加リソースへのアクセスを含めるように将来のリリースで拡張する予定で、よりわくわくするような統合の可能性を作りだす予定です。現在のリリースのAPIのドキュメントは以下からご覧ください。
REST API for Oracle Real-Time Integration Business Insight
http://docs.oracle.com/cloud/latest/soa122100/INAPI/index.html
概要の動画、チュートリアル、メディアのダウンロードなどを含めて、Oracle Real-Time Integration Business Insightについての詳細は、, including overview videos, tutorials, downloads, and more,製品ページをご覧ください。
Oracle Real-Time Integration Business Insight
http://www.oracle.com/technetwork/middleware/insight/overview/index.html 

[Cloud] Instance and storage snapshot

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

昨日はOracle Public Cloudの3個のサーバ上にE-Business Suite 12.5.5のインスタンスを作成していきました。
E-Business Suite in the Oracle Cloud
https://blogs.oracle.com/pshuff/entry/e_business_suite_in_the
その前日、データベースを隠し、パブリック・インターネットからアクセスできないようにして、アプリケーション・サーバーのみデータベース・インスタンスに接続できるようにすることで、これらのインスタンスを保護する方法について説明しました。
hiding a server in the cloud
https://blogs.oracle.com/pshuff/entry/hiding_a_server_in_the
本日は、アーキテクトとしての作業が終わり、バックアップする必要があるという前提とします。まずは標準のufsdumpを使い、ネットワーク・ストレージにシステムのバックアップをとることができるでしょう。これだけではクラウドの半分の問題しか解決しません。データをリストアできますがクラウドの世界ではちょいと事情が異なります。セキュリティ・リスト、セキュリティ・ルール、インスタンスの構成もバックアップする必要があります。この環境を開発・テストもしくはQAのセカンダリ環境にレプリケートしたいと思うかもしれません。それゆえ、ゴールデンマスターを作成するのがよさそうです。
Oracle Cloudでは、インスタンスのスナップショットだけでなく、ストレージのスナップショットもとることができます。これは、既存のインスタンスを複製し、必要な時にプロビジョニングできることを意味しますが、これはバックアップとは異なります。バックアップとは通常固定されたコンピュータ・アーキテクチャを想定しており、OSやアプリケーションコードをディスク上に戻すことができます。事態が変化し、オンプレミスデータセンターとの通信に使う仮想プライベートネットワークを追加する場合、ネットワークディスク上のバックアップにはその構成がない可能性があります。これはVMWareと同様のケースであることが多くの顧客は知っています。Software Defined Networkを使ってネットワークを再定義し、仮想ディスクや仮想ネットワークインターフェースを作成できる場合、こうした追加構成はufsdumpやOSレベルのバックアップには存在しません。本当に仮想ディスクおよびその構成のクローンを作成する必要があります。
Oracleは、Cloud Serviceの5月/6月のアップデートで、ストレージのスナップショットだけでなく、インスタンスのスナップショット機能をリリースしました。ストレージ・スナップショットについては制限はありませんが、インスタンス・スナップショットには少々制限があります。インスタンス・スナップショットは、非永続的ブートディスクである必要があります。これは、ディスクを事前に作成し、インスタンスにアタッチし、そのディスクからブートしないことを意味します。ディスクは、終了すると削除される特性を持っている必要があります。これは率直に言って非常に危険なように見えます。/etc にユーザーアカウントを追加したり、/etc/initにinitファイルを追加するようなカスタマイズを施した場合、これらのカスタマイズが終了と同時に削除されるからです。ここで重要なのは、インスタンスを作成し、カスタマイズして、そのスナップショットを取るということです。そして、OSのバニラ・イメージからではなく、このスナップショットから起動します。
まず、ストレージスナップショットから見ていきましょう。オンラインドキュメントにコンソール操作、REST API、コマンドラインインターフェースの詳細があります。
Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)
Backing Up and Restoring Storage Volumes Using Snapshots
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-0C04E7C5-0D24-4D16-9D83-92EC1E737622.htm#STCSG-GUID-0C04E7C5-0D24-4D16-9D83-92EC1E737622
REST API for Oracle Compute Cloud Service (IaaS)
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/toc.htm
Oracle® Cloud Command Line Reference for Oracle Compute Cloud Service (IaaS)
https://docs.oracle.com/cloud/latest/stcomputecs/STCLR/toc.htm
REST APIには少々深掘りするに値する機能があります。REST APIのドキュメントによれば、同じサーバにスナップショットを作成することができます。これは、スナップショット作成時にプロパティとして/oracle/private/storage/snapshot/collocatedを指定することによってより高速にリストアできるようにするものです。
REST API for Oracle Compute Cloud Service (IaaS)
Storage Volume Snapshots REST Endpoints
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/api-Storage%20Volume%20Snapshots.html 
また、以下のAPIを使うと、ストレージボリュームをスナップショットから作成できます。
REST API for Oracle Compute Cloud Service (IaaS) 
Create a Storage Volume
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/op-storage-volume--post.html 
Computeコンソールからこれらの機能のほとんどを操作できます。ストレージボリュームを選択し、[スナップショットの作成]を選択します。

起動可能ディスクとしてこのスナップショットをリストアすることができる状態にあります。そしてこのボリュームを基にして新規インスタンスを作成することができます。ストレージスナップショットのタブへ移動し、[ボリュームの復元]を選択して、リストアします。

インスタンス・スナップショットも作成できます。インスタンス・スナップショット作成にあたっての重要な制限事項は、そのディスクが非永続でなければならない、ということです。つまり、インスタンスの一部として作成し、マウントされるのではなく、終了時にディスクは削除されます。これは最初少々途惑うところではあります。デフォルトのインスタンス作成に従うと、ストレージボリュームが作成されます。このストレージボリュームを削除して、終了時に削除されるルートディスクに置き換える必要があります。インスタンス作成の手順において、ストレージ作成時に挙動を変更する必要があります。デフォルトではストレージインスタンスを作成します。そのストレージインスタンスを削除すると、自動的に非永続ボリュームで置き換えられます。

このハードルがなくなれば、インスタンス・スナップショットを作成することができます。インスタンスを選択し、[スナップショットの作成]をメニューから選択します。グレーアウトしていて選択できない場合、永続ストレージボリュームをブート・イメージとして使っています。

スナップショットのメニューをクリックしてこのスナップショットをイメージと関連付けると、起動可能イメージをこのスナップショットを基に作成することができます。これを使うと自身が作成したイメージでインスタンスを作成することができます。

インスタンス・スナップショット使用の鍵は、起動可能なインスタンスを作成し、望むように設定してから、このインスタンスのスナップショットを作成することです。こうすることで、起動可能ディスクだけでなく、そのインスタンスに対して実施したネットワーク設定やカスタマイズのゴールデンマスタを作成することができます。インスタンス・スナップショットの場合は少々異なった考え方をする必要があります。永続ルートディスクを持たないことが奇異に映るかもしれません。任意のカスタマイズが再起動時に失われることを知ると少し奇妙なことでしょう。デフォルトのログファイルが再起動時に一掃されることを知ると少し奇妙に思うことでしょう。通常とは少々異なる考え方で、ログや構成、カスタマイズを再構成し、デフォルトのルートディスクではなく、別のディスクに保存するようにする必要があります。これはそれほど悪い話ではありません。ルートディスクが保護され、カスタマイズされません。カスタマイズした場合には、それはどこかのタイミングで凍結保存してください。この方法の大きな利点の1つは、カーネルにルートキットを挿入できないということです。こうした種類の侵入は、通常マルウェアをロードするために再起動が必要です。再起動すると、安心・安全なカーネルとデフォルトのライブラリに戻ります。これはつまり、任意のパッケージやカスタマイズはこのカスタマイズ用に新しくスナップショットを永続化する必要がある、ということです。
まとめると、スナップショットはストレージやインスタンスを凍結保存するよい方法です。これを使うと開発やテストにあたって簡単に複製できるゴールデンマスタを作成することができます。さらに、必要なパッケージを有するブートディスクを凍結することで、再起動が必要なマルウェアをロックアウトできるという意味で、新しいレベルのセキュリティも追加します。パッケージやルートファイルのカスタマイズには新しいスナップショットを持つ新しいゴールデンマスタが必要である、という新しい考え方が加わります。このエントリがスナップショットの利用や、スナップショットを利用する上でのベストプラクティス方法論の作成にあたってお役に立つことを願っています。