要約

  • 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、顧客、配備、事故、アーキテクチャを作っていない。証拠層を分けることが、過大評価を避ける条件である。

公開情報源