要約

  • APNICのRDAPはAS9334をiManila-AS-APとして記録し、国をフィリピン、登録組織をORG-IA76-APとしている。管理、技術、abuseの連絡先は公開調整面を作るが、連絡先の存在だけで応答時間は証明できない。
  • 2026年7月31日の照会時、RIPEstatは203.167.0.0/21をAS9334起源として観測していた。routing-statusは2,048アドレスを含む一つのIPv4プレフィックスを示し、その応答ではIPv6プレフィックスを示さなかった。これは時刻と観測範囲を持つスナップショットであり、恒久的な資源一覧ではない。
  • RPKI検証はAS9334と203.167.0.0/21の組み合わせをvalidと判定した。これは経路起源の認可に関する限定的な結果であり、経路漏えい、設定誤り、停止、DNS、サーバー、アプリケーションの障害を防ぐ保証ではない。
  • iManilaは共有ホスティング、Business Cloud、専用サーバー、サーバー管理、Webサイトバックアップ、セキュリティ、ドメインの機能を公開している。製品能力の記述は、可用性、復旧成功、セキュリティ効果、顧客満足の独立測定ではない。
  • SLAは99.5%のネットワーク稼働率保証と、定義、除外、請求手続きを示す。契約上の約束は観測結果ではない。
  • 掲載写真は2011年に撮影されたツーソンのNOIRLab本部サーバーラックである。一般的なホスティング運用の文脈に限って使い、iManilaの施設、システム、顧客、容量、セキュリティ、成果を表すものではない。

AS9334は説明可能な登録対象

Autonomous System Numberは、組織間ルーティングで一意の主体を識別するための番号である。番号だけでは企業、物理ネットワーク、トポロジー、品質を表さない。運用上の価値は、一意性、登録の正確さ、有効な連絡先、そして登録された意図と実行中の設定との整合に依存する。

APNICの記録はAS9334をiManila-AS-APおよびORG-IA76-APと結び付ける。APNICは登録制度と記録環境を維持する。認可された運用者は自分の情報を更新する。他のネットワークは経路を受け入れるか、フィルタするかを独立に決める。外部観測者は分散システムの一部だけを見る。

したがって、レジストリは運用台帳であって、ネットワークの主権的所有者ではない。203.167.0.0/21がAS9334起源として観測されたことは、iManilaが全アドレスを絶対所有することや、全製品がこの経路だけで提供されることを証明しない。登録、起源、物理管理、商業上の支配、個別アプリケーションの利用は別の事実である。

連絡先も同様である。技術またはabuse連絡先が公開されていることは調整経路を作る。しかし、メールボックスが常時監視され、正しい担当者に届き、一定時間内に閉じられることは別の信頼性問題である。

記録の維持には継続コストがある。人員、役割、メール、組織名、経路意図は変化する。古い記録はインシデント調整を遅らせる。変更手続きが弱すぎれば不正更新の危険があり、難しすぎれば情報が陳腐化する。必要なのは認可、監査、確認、訂正であるが、公開資料からiManilaの内部手順を推測することはできない。

RIPEstatが示す範囲

照会時、RIPEstatはAS9334をannouncedとし、routing-statusとannounced-prefixesで203.167.0.0/21を示した。BGP-stateにはAS9334で終わる公開パスが含まれていた。これは登録識別子と外部から見える状態を関連付けるが、完全なネットワーク図ではない。

BGPは分散制御系である。Route collectorは参加ネットワークから受け取った経路を観測するだけで、インターネット上の全地点を代表しない。あるプレフィックスは多数の観測点で見えても、別のネットワークでフィルタされることがある。保守で一時的にwithdrawされることもある。複数の観測者が異なるパスを見ることも正常に起こり得る。

公開パスから物理回線の独立性、容量、契約、テスト済みフェイルオーバーを推定してはならない。経路が見えても、パケット損失、遅延、輻輳、DNS、サーバー、アプリケーションの状態は分からない。

IPv6が表示されなかった点も限定する必要がある。そのendpointが当時AS9334のIPv6プレフィックスを示さなかっただけであり、すべての製品、プライベートセグメント、上流接続、将来展開でIPv6能力がないことを意味しない。

有効な監視は、承認された期待状態、保守時間、変更記録、複数の時刻付き観測を比較する。差異が出たときは、計画保守、フィルタ、セッション障害、設定誤り、収集上の限界を分類する必要がある。自動化は差異を発見できるが、その差異が意図どおりかを決めるには責任者と文脈が必要である。

RPKIのvalidは限定された安全情報

RPKIの結果は、照会時の検証データに基づき、AS9334を203.167.0.0/21の起源として認可していたことを示す。これは重要だが、範囲が狭い。

ROVは完全なASパスを認証しない。すべてのネットワークにinvalid経路の拒否を強制しない。認可された起源の設定ミスも防がない。valid経路の先に停止したサーバーがある場合もある。DNS、ファイアウォール、証明書、ストレージ、データベース、アプリケーションはRPKIとは独立に失敗し得る。

ROA自体も保守対象である。プレフィックス、origin ASN、maxLengthは予定する公告に合う必要がある。起源変更やmore-specific公告では更新が必要になることがある。広すぎる認可と狭すぎる認可は異なるリスクを作る。公開結果はiManilaの鍵管理、承認者、緊急変更を示さない。

したがって、RPKIは起源統制であり、サービス全体の安全性や稼働率を表すバッジではない。

ホスティングの名称より責任の配置を見る

iManilaの公開ポートフォリオには、共有Web・メール、Business Cloud、専用サーバー、Server Management、Webサイトバックアップ、セキュリティ、ドメイン関連サービスが含まれる。各モデルは実際の制御権を異なる当事者に置く。

共有ホスティングでは、提供者が共通基盤の多くを運用し、顧客がコンテンツ、認証情報、アプリケーション選択を管理する。顧客の直接作業は減るが、基盤変更の自由は小さい。資源圧迫、メール評判、ソフトウェア互換性、セキュリティ事象がアカウント境界を越える可能性がある。

Business Cloudは資源選択とcPanelによるファイルやバックアップ操作を提供する。Cloudという言葉だけでは冗長性や回復性は証明できない。結果はネットワーク、ストレージ、プラットフォーム、資源配分、監視、パッチ、アクセス、復旧設計に依存する。

専用サーバーではroot、WHM/cPanel、アカウント管理などにより顧客の制御が増える。その代わり、特権アクセス、OSパッチ、ログ、容量、データベース、ファイアウォール、証明書、バックアップの責任も顧客側に移る。Managed契約が明確に引き受ける部分だけが例外である。

Server Managementでは、iManilaが監視、更新、パッチ、移行、ファイアウォール、SSL、Web・DBサーバー、ドメイン、cPanelを公開範囲として挙げる。この範囲は能力と責任の説明であり、実行頻度、例外優先度、特定作業の成功を証明しない。

比較すべきはラベルではなく、誰が観測し、誰が変更し、誰が停止を承認し、誰が結果を確認できるかである。責任が不明確なら、顧客と提供者が同じ作業を重複するか、双方が相手の担当だと考える。

自主管理と管理サービスの監督コスト

自主管理の専用サーバーは、認可された技術者が直接変更できる。専門要件には有利だが、顧客はパッチ、監視、ログ、バックアップ、脆弱性、容量、当番を継続する必要がある。

管理サービスは定型作業を提供者に移せるが、引き継ぎが増える。提供者は正しいアクセス、希望状態、保守窓、承認を必要とする。顧客はアプリケーション要件と結果を確認する必要がある。緊急時に認証情報や承認者が古ければ、管理契約があっても修復は遅れる。

どちらにも監督がある。自主管理は自社の人員と変更を監督し、管理サービスは範囲、アクセス、依頼、証拠、結果を監督する。経済的な問いは「労働が消えたか」ではなく、総作業、待ち時間、リスクが減ったかである。

DNSは小さいが重要な制御面

iManilaのDNS説明は、ホストされたnameserverと外部DNSの責任を区別する。サーバーが正常でも、レコードが誤ったアドレスを指せばサービスは届かない。Zoneが正しくてもdelegationが誤れば解決できない。メールと証明書は追加レコードに依存する。

継続性には、registrar、delegation、authoritative server、zone owner、回復アクセス、重要レコード、検証方法の一覧が必要である。移行中はTTLとキャッシュによって新旧両方にトラフィックが分かれる。

外部DNSを利用する顧客の場合、iManilaがサーバーをホストしてもDNS層を修復できないことがある。逆に顧客は正しい値を知っていてもauthoritative serviceを操作できないことがある。「Webサイトが開かない」という症状を、実際に制御できる層へ分解する必要がある。

SSHと特権アクセス

WHM/SSHのガイドは遠隔管理の入口を示す。SSHは診断、設定、配備、復旧を可能にするため、本人確認、認証、権限、失効、ログが必要である。

共有パスワードは責任を曖昧にし、長期鍵は人員や委託契約の終了後も残る可能性がある。緊急アクセスは停止時に重要だが、統制を完全に迂回すれば別の危険になる。制限が強すぎても修復を遅らせる。

SSH自体もネットワークとホストに依存する。ファイアウォール、経路、満杯のディスク、セキュリティ隔離が接続を止める。ログイン失敗は認証情報、ネットワーク、ホスト、ポリシーのどれでも起こり得る。分類前に複数層を変更すると障害を悪化させる。

公開ガイドはインターフェースの存在を示すだけで、iManilaの秘密鍵管理やbastion構成を示さない。

バックアップと復旧

iManilaのWebサイトバックアップページはバックアップと復元の能力を説明する。バックアップは削除、破損、侵害、変更失敗の不可逆性を下げるが、job成功はサービス復旧と同じではない。

データが不完全、DB状態が不整合、鍵や証明書がない、保持期間が短い、復元先容量が足りない場合がある。バックアップが本番と同じ認証情報や障害領域を共有することもある。

復旧計画にはRPO、RTO、担当者、鍵、クリーンな復元先、検証条件が必要である。確認すべきはファイル取得ではなく、定義したアプリケーションが動作すること。提供者が基盤を運用しても、顧客は重要データを定義し、業務動作を確認する責任を持つ場合がある。

バックアップは退出ともつながる。契約終了後にアクセスできなければ価値は低下する。形式、転送時間、帯域、認証、削除期限を健康な時点で試す必要がある。

パッチ、証明書、ファイアウォール

Server Managementの範囲には更新、パッチ、ファイアウォール、SSL、Web、DBがある。パッチ延期は既知脆弱性を残し、無試験適用はアプリを壊す。EOLソフトウェアは両方の選択を難しくする。

証明書の期限は予測できるが、DNS、権限、challenge設定で自動更新が失敗する。監視はコマンド成功ではなく、実際に配備された証明書を確認すべきである。

ファイアウォールは露出を減らす一方、業務や管理を誤って止める。ネットワーク、ホスト、アプリの複数層にルールがあると、一層の修正だけでは回復しない。

これらは管理サービスへの批判ではなく、サービスを成立させる作業である。公開範囲は責任分担に役立つが、iManilaのパッチ率や証明書障害履歴を示さない。

99.5%保証の読み方

SLAの99.5%ネットワーク稼働率保証は、測定期間、稼働の定義、保守、除外、credit申請に依存する。

ネットワーク稼働は、アプリケーションエラー、顧客設定、外部DNS、第三者、非対応ソフトウェアを含まない可能性がある。顧客が取引を完了できなくても、契約指標が範囲内の場合がある。creditも人件費や事業影響を補償するとは限らない。

本稿は稼働率を測定していない。保証の達成や違反を主張できない。契約は責任と救済の境界を示す資料としてのみ使う。

想定すべき失敗モード

以下は公開インターフェースから導けるリスク分類であり、iManilaで発生した個別事故の報告ではない。

  1. 組織、技術、abuse連絡先の陳腐化。
  2. 予定経路と外部観測の不一致。
  3. originやプレフィックス変更にROAが追随しない。
  4. DNS delegationまたはzoneの誤り。
  5. 特権アクセスの喪失、期限切れ、侵害。
  6. CPU、メモリ、ストレージ、DB、接続、メール、帯域の圧迫。
  7. パッチ非互換またはEOLソフトウェア。
  8. バックアップはあるが完全サービスを復元できない。
  9. abuseや侵害により隔離、停止、証拠保全が必要になる。
  10. 提供者と顧客が障害層を互いの責任と考える。
  11. 移行がファイルだけで、DB、DNS、メール、証明書、taskを漏らす。
  12. 期限、終了、削除が必要なexportより先に来る。

例外処理には証拠、所有者、行動権限、終了条件が必要である。アラート数が増えても、制御できる人に届かなければ信頼性は上がらない。

移行、可搬性、終了

iManilaの条件は有効化、更新、資源制限、移行、停止、終了、削除、DNS、IP放棄を扱う。可搬性はファイルだけではなく、DB、アカウント、メール、証明書、ログ、scheduled task、firewall、ライセンス、外部統合を含む。

IP allowlistや相手先設定に使うアドレスは移動できないことがある。ドメインは移せても、delegation、DNSSEC、zone、credential、lockは調整が必要である。新旧環境のデータが分岐するとrollbackは難しくなる。

健全な時期に、代表データのexport、隔離先での再構築、DNS・証明書の検証、IP依存の識別、転送時間の測定を行うべきである。これはiManilaの移行失敗を主張するものではなく、公開条件に示された退出面への備えである。

能力、信頼性、顧客成果を分離する

APNICは登録識別を支える。RIPEstatは時刻付き観測を支える。iManilaのページは能力説明を支える。SLAは約束と救済を支える。製品信頼性には稼働、エラー、安定性、復旧、修復時間の反復測定が必要である。顧客成果には具体的な顧客、ワークロード、目的、方法が必要である。

本稿では非公開テストを行わず、benchmark、顧客、配備、事故、アーキテクチャを作っていない。証拠層を分けることが、過大評価を避ける条件である。

公開情報源