ShinobiLayer: SoftLayerのXen脆弱性に伴う再起動：FAQとHint & Tips

1. はじめに

SoftLayerとSoftLayer利用者の間の責任分解点として、SoftLayerは仮想サーバーのHypervisorにおける運用責任を、お客様はOS以上の運用責任を担っています。
つまり、SoftLayerの仮想サーバーのHypervisorのセキュリティーに関してもSoftLayerが担っているということを指します。SoftLayerの仮想サーバーはXenServer上で稼動していますが、本執筆時点ではXen脆弱性対応のためにSoftLayerはHypervisorの再起動を要するため、利用者の仮想サーバーの停止を伴う可能性があります。この再起動に伴うFAQとHint & Tipsをまとめました。

2. メンテナンス通知を受け取るためにはどうすればいいの？

Xen脆弱性に伴うセキュリティパッチ適用は、計画されたイベントです。よって、Planned Eventとしての通知を事前に受け取るはずです。また、進捗状況も随時PortalおよびTicketにて通知されます。これらの通知を受け取るためには、SoftLayerのCustomer Portalにて、

1. 下図のようにAccount -> Manage -> Subscriptionsを選択し、
   
2. Planned Maintenanceを選択したあと、
   
3. 各メンバーに対してSubscribedにチェックを入れる必要があります。
   

Xen脆弱性に伴う再起動はPlanned Maintenanceに相当しますが、もし障害などの情報も取得したい場合は、同様の手順に従ってUnplanned Maintenanceも設定しておきましょう。
ちなみに、BluemixもSoftLayer上のサービスとして稼動しています。Bluemixも同じタイミングでメンテナンスが実施されますが、サービスとして実装している都合上、SoftLayer本体とはメンテナンス時間が異なります。詳細は以下をご確認ください。
http://qiita.com/mfujita/items/bd7962ebdbce3082888f

3. 私のサーバーはどのPoDで動いているの？

SoftLayerのデータセンターは、PoD(Point of Delivery)という単位ごとに拡張されています。なので、同一データセンターの中でも、PoD1、PoD2、Pod3、、、という風に複数のPoDが存在します。
本執筆時点では、各データセンターごとにPoD単位で順次実施されるようです。よって、自分のサーバーがどのデータセンターで動いているかだけでなく、どのPoDに存在するかも常に意識しておく必要があります。

DAL09Singaporeのメンテナンス通知の例

12:01 am CDT - DAL09 pod1 Start 
01:30 am CDT - DAL09 pod2 Start 
03:00 am CDT - DAL09 pod3 Start 
04:30 am CDT - DAL09 pod4 Start 
06:00 am CDT - DAL09 pod6 Start

では、どうやって自分のPoD調べるのでしょうか？方法は幾つかありますが、一番簡単な方法は、該当サーバーが利用しているfcrやbcrの番号がPoDに対応しているので、この番号を確認することです。例えば、

• Devices -> Device Listから該当サーバーを選択し、Network構成でのVLAN情報を確認。この図からは、sng01.fcr02a.1721やsng01.bcr02a.1906となっているので、PoD2に存在することが分かる。
  
• Network -> Status -> Localより、sing01.softlayer.comというサーバーは、bcr01a.sng01.softlayer.comに属しているのでPoD1に、sing02.softlayer.comというサーバーは、bcr02a.sng01.softlayer.comに属しているのでPoD2に存在することが分かる。
  
• Network -> IP Management -> VLANsより、該当VLANがどのfcr/bcrに属しているかが分かる。この例だと、VLAN1288/1405/2379はfcr01a.sng01やbcr01a.sng01に紐づいているのでPoD1に属している。一方、VLAN1721/1906はPoD2に属している。（このVLANのリンクをクリックすると、割り当てられているsubnetやサーバー一覧を確認することが可能）

4. 再起動に伴う影響と、事前の対応は何をするべきなの？

• Xen脆弱性メンテナンスにはHypervisorの再起動を伴うことがあります（再起動が不要のメンテナンスもありますので、Ticketをお読みください）。本執筆時点においては、「Xen Motionのようなもので、別ホストサーバーに無停止で移動することで、Hypervisorのメンテナンスの影響は受けない・・・」という対応はありません。よって、Hypervisorの再起動が発生する場合は、仮想サーバーの再起動も伴います。
• 仮想サーバーの再起動が必要な場合は、XenToolsなどの機能を利用して、仮想サーバーのsoftware shutdownを試みます。SoftLayerが勝手にお客様環境に個別ログインできないので、これがSoftLayerにできる最大限の努力です。もしsoftware shutdownに失敗した場合は、hardware shutdown（いきなり電源断が発生したのと同じ）が行われます。停止手段に関する保障はありませんので、安全な停止を求める場合や、ミドルウェアの停止順序などが重要である場合は、利用者側で事前に停止しておくのが良いでしょう。
• メンテナンス終了後は、もし自分で明示的に仮想サーバーを停止していても、Hypervisorの起動と共に仮想サーバーも自動的に起動されます。このため、サービスが完全に起動が完了しない状態で、想定外のアクセスが来る可能性もあるでしょう。こうした事態を避けるためには、OS再起動が発生してもアプリケーション側でサービス閉塞してアクセスが来ないようにしておくとか、ミドルウェアを自動起動しないように設定しておくなどの対応が必要です。
• メンテナンス終了後は、再度アプリケーションの稼動テストを実施されることを推奨します。（理想的には、クラウドらしくテストの自動化を実行しておくと良いでしょう）。

5. 事前にどういう脆弱性なのかを教えてくれないの？

利用者への説明のために事前に情報が欲しいと言われることもありますが、（Ticketで問い合わせても、IBMの営業さんにいくら迫っても）教えてくれません。

こうした深刻な脆弱性情報は、開発元であるCiTRIX社から秘密保持契約を結んだ上で、事前に情報提供を受けています。その情報を元に、SoftLayerは事前に検証・パッチ適用を行っています。この手の情報は事前にどういう脆弱性があるかが世間に広まってしまうと、その情報を元にpatch適用前に攻撃されてしまう可能性がありますよね？ なので、すべてが終わってからじゃないと、その脆弱性がどういうものなのかという問い合わせは受け付けてくれませんし、その前提でCiTRIX社から事前に情報提供を受けているのです。
※補足: IPA（情報処理推進機構）が公開している「情報セキュリティ10大脅威 2016」において、脆弱性対策情報の公開に伴い公知となる脆弱性の悪用増加が10位に浮上していました。このことからも、脆弱性対策情報の公開から攻撃までの期間が大変短くなっている傾向があることもご周知おき下さい。

今までの自社サイトにおけるセキュリティー対策においては、”既に世の中に知れ渡っている脆弱性”の情報を入手して対策を施していたのかもしれませんが、それってちょっと考えてみるとおかしいですよね？既に知れ渡っている脆弱性に対してセキュリティー対策を実施しないなんていう選択肢は普通はありえませんし、その対策を実施するまではずっと放置しているという状況もおかしなものです。
逆に言うと、一企業が製品開発元と個別の秘密保持契約を結んで、一般公開前に脆弱性情報提供を受けて事前に対策を施すというアクションを採ることは、なかなか大変なことだと思われます。こうした事前の情報提示は対象が大手クラウドベンダーだから初めてもらえるものです。クラウド提供業者によるセキュリティー責任部分を、確実に担保するための仕組みと言えそうです。

一般には、SoftLayerから再起動の通知を受けた際に、以下のリンクからPublic releaseは再起動直後なのにCVEやTitleが明確になっていないものがあるので、（内容は分かりませんが）これが該当しているんだなーっていう想像は付くと思います。
http://xenbits.xen.org/xsa/

6. メンテナンス時間は調整できないの？

（Ticketで問い合わせても、IBMの営業さんにいくら迫っても）受け付けてくれません。

過去の事例としては、各データセンターにおいて深夜00:00から開始されているようです。ただし、ユーザー個別に調整をすることはできません。この辺りの考え方は利用者としてもセキュリティーに対する意識を変えるべきポイントです。仮想サーバーのHypervisorのセキュリティー対策をクラウド業者に委任しているのですから、クラウド業者が開発ベンダーからの方針に従う必要があります。以下のように考えてみると、この対応は仕方がないように思います。

• 個別対応を受けてしまうと、迅速なパッチ適用ができなくなります。一般に緊急性の高いセキュリティーパッチは、開発元であるCiTRIXから情報提供があってから一般公開されるまでにそんなに期間的に猶予があるわけではありません。クラウド業者としては、大量の仮想サーバーに対して迅速に適用する必要があります。
• あるサーバーだけパッチの適用時期がずれてしまうと、管理がばらばらになってしまいます。また、そのサーバーを基点に攻撃されてしまう可能性があります。利用者のみなさんは、自社都合によって、クラウド基盤全体が攻撃を受けてしまう可能性に対する責任を取れないと思います。

7. サーバーが止まるなんて、SLA違反じゃないの？

いいえ。本作業は事前に通知された"計画停止"なので、SLA違反には該当しません。SLAの詳細に関しては、http://www.softlayer.com/legal を参照してください（SoftLayerは個々のサーバー障害に対しても、SLAは提供していません。）

8. この影響を最小化するためには、どのような構成が適切なの？

投資などの理論と同じく、リスク対策の基本は「卵は一つのカゴに盛るな」です。

• 複数のデータセンターを組み合わせる。
• 物理サーバーもしくは物理サーバーに自分でHypervisorを導入し、これらと組み合わせて分散配置する（物理サーバーのメンテナンス・セキュリティー対策は自己責任なので、SoftLayerのXen脆弱性メンテナンスの影響は受けない。）
• 異なるHypervisorを提供している別クラウドと組み合わせて分散配置する（Hybird Cloud/Multi Cloud）

9. 今後の改善計画は？

Publickeyでも紹介されていましたが、再起動なしでパッチを当てられるLive Patchingの技術の採用を検討されているようです。ただし、新しい技術ですし、必ずしも全てのセキュリティーパッチが無停止で適用できるという保障がある訳ではありません。当然、全世界のデータセンターで運用するためのノウハウも今後蓄積していく必要があるでしょう。このLive Patchingのバグで結局再起動になってしまった・・・となると目も当てられません。この辺りは慎重に検討・採用されていくと思われます。残念ながら、リリース時期は未定です。