2026年10月28日
ガイダンスWGリーダー 諸角昌宏
本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。
本ブログの位置づけ
2026年10月、GMOが提供する「お名前.com デスクトップクラウド」(以下「本サービス」)において、不正アクセスが公表された[10]。「クラウド」という名称を付けていることもあり、クラウドセキュリティの観点からそもそもどのようなサービスモデルなのか、また、責任範囲は事業者と利用者でどうなるのかを考えてみたい。そこで、公開されている告知等をもとに、本サービスの構造とセキュリティ上の責任分界を技術面から整理してみる(2026年10月27日時点の公開情報にもとづく)。なお、利用規約の条文は確認しておらず、契約上の責任を確定するものではない。このため、本ブログでいう「責任」「管理範囲」は、各層を誰が設定・運用・保護する立場にあるかという技術面での分担を指し、契約上の義務や法的な賠償責任を意味しない。
本ブログで用いる用語と表記は次のとおりとする。
- 共通管理基盤:事業者が全VMに対して特権的に操作できる仕組みと、全VMに共通して配布・適用される要素の総称。本ブログでは、マネジメントプレーン、コントロールプレーン、ハイパーバイザー、全VM共通のVMイメージ、管理エージェント(存在する場合)を含む(3章)。
- 利用者:本サービスの契約者。
- 根拠の表記:本文中の[番号]は巻末の出典に対応する。番号のない記述は一般論または本書の想定である。
要点
- 位置づけ:本サービスは、確認できる範囲では1利用者に1台のWindows Server VMを割り当て、リモートデスクトップで操作する形態であり、「仮想デスクトップ用途向けのWindows VPSに近いサービス」と整理できる(1章)。
- 責任分界:物理基盤と共通管理基盤は事業者、ゲストOSやMT4の更新の適用、EA、保存した認証情報、データは利用者が担うと整理できる。このうち緊急のセキュリティ更新の適用とOS提供終了時の再インストールは、告知で利用者に求められている(2章)。
- 前提:この分担は、事業者が共通管理基盤を適切に管理していることを前提とする。共通管理基盤が侵害されるとVM内の対策は迂回されうるため、この前提が成り立たなくなり、被害を抑える手段は取引口座側の対策が中心になる(3章)。
1. 「お名前.com デスクトップクラウド」のクラウドサービスとしての位置づけ
「お名前.com デスクトップクラウド」はGMOの商品名であり、VDIやDaaSのような技術・提供形態の分類用語ではない。分類を検討する際は名称だけでなく、提供機能、管理機能、利用者が管理する範囲を確認する必要がある。
確認できる範囲では、本サービスは1利用者に1台のWindows Server VMを割り当て、利用者がリモートデスクトップで接続して操作する[1][3]。GMOは料金改定の告知で本サービスを「FX専用VPS」と表記しており[3]、緊急のセキュリティ更新の適用[8]やOS提供終了時の再インストール[9]は利用者に求められている(詳細は2.1、2.2)。本ブログでは、これらの特徴をもとに、本サービスがクラウドのサービスモデルの中でどこに位置づけられるかを整理する。
1.1 用語の整理
| 用語 | 意味 |
| VDI | デスクトップ環境をサーバー上の仮想マシンで動かし、手元の端末から画面を操作する技術・仕組み。オンプレミスでも構築でき、それ自体はクラウドとは限らない |
| DaaS | VDIを事業者がサービスとして提供する形態(Azure Virtual Desktop、Windows 365、Amazon WorkSpacesなど) |
| VPS | 事業者の物理サーバー上の仮想マシンを1台単位で貸すサービス。用途は利用者次第 |
| IaaS | 仮想マシン、ネットワーク、ストレージなどのインフラをサービスとして提供する形態(AWS、Azure、GCPなど) |
| SaaS | アプリケーションの機能をサービスとして提供する形態。利用者はOSに触れない |
1.2 VDI・DaaSとSaaSの関係
VDIはデスクトップ環境を仮想化して利用する技術・仕組みであり、それ自体がSaaSを意味するわけではない。クラウドでデスクトップ環境をサービス提供する形態は一般にDaaSと呼ばれる。IaaS・DaaS・SaaSの一般的な責任分界は下表のとおりである。ただし、責任分界はサービスごとに異なり、DaaSだからOS管理を一律に利用者が担う、または事業者が担うとは限らない。利用する際に、責任範囲を明確にすることが必要である。
| 層 | IaaS | DaaS(典型的) | SaaS |
| 物理基盤・仮想化基盤 | 事業者 | 事業者 | 事業者 |
| 接続の仲介・認証ゲートウェイ | 利用者が構成(部品は事業者が提供) | 事業者 | 事業者 |
| デスクトップのOS・パッチ | 利用者 | 製品により事業者か利用者 | 事業者 |
| アプリ・データ・アカウント管理 | 利用者 | 利用者 | 利用者(データとアカウント) |
1.3 VPSとDaaSの違い
DaaSには一般に、接続仲介、利用者・セッション管理、イメージ管理、コピー&ペーストや印刷等の制御機能が含まれることがある。ただし、機能の有無は製品・サービスによって異なる。Windows VPSにRDPで接続する形態は見た目がデスクトップサービスに似ていても、管理機能や責任分界が同一とは限らない。
1.4 VPSとIaaSの関係
VPSとIaaSは、仮想マシンを借りて利用者がOSから上を管理する点で共通する。IaaSではAPI、仮想ネットワーク、ロードバランサー、マネージドDB、IAM、監査ログ、鍵管理等の機能が提供されることが多い。これらは一般的な傾向であり、VPSとIaaSの境界は事業者およびサービスによって異なる。
1.5 「お名前.com デスクトップクラウド」はクラウドか(NISTの定義との照合)
NIST SP 800-145[11]はクラウドの必須の特徴を5つ挙げている。公開情報で確認できる範囲で本サービスを当てはめると次のようになる。
| NISTの特徴 | 内容 | 本サービス(公開情報上) |
| オンデマンド・セルフサービス | 事業者とやりとりせず、利用者が自分でリソースを用意できる | 一部確認できる(OS再インストールを利用者がコントロールパネルから行える[9]。申し込み、起動・停止は未確認) |
| 幅広いネットワークアクセス | ネットワーク経由で様々な端末から使える | 満たす(PC・タブレット・スマートフォンから接続できる[3]) |
| リソースプール | 複数の利用者で物理リソースを共有し、動的に割り当てる | 共有はうかがえる(サーバーの収容効率に触れた告知がある[2])が、動的な割り当ては未確認 |
| 迅速な弾力性 | 必要に応じて素早く拡大・縮小できる。場合によっては自動で | 未確認(プラン変更の可否、即時性、自動化の有無を確認していない) |
| 計測可能なサービス | リソースの使用量を計測し、管理・報告できる | 未確認(料金は契約期間ごとの定額[5]。使用量の計測・報告機能は確認できない) |
未確認の項目があるため、公開情報だけでは本サービスがNISTの定義を満たすかどうかは判定できない。ただし、迅速な弾力性は自動であることを必須とせず、計測可能なサービスも従量課金そのものを求めていないため、仮にこれらが限定的であっても、それだけで直ちに定義から外れるわけではない。VPSとクラウドの関係はグレーゾーンにあり、実務上の区別は、定義から外れるかどうかより、弾力性・API・周辺サービスの充実度の差によるところが大きい。
1.6 本サービスの位置づけ
- GMO自身が料金改定の告知で「FX専用VPS」と表記している[3]。
- DaaSに一般にみられる管理機能(接続の仲介、組織アカウントとの連携、イメージの一括管理等)は、公開情報からは確認できない。緊急のセキュリティ更新の適用[8]や、OS提供終了時の再インストール[9]は利用者に求められている。
- 以上から、本ブログでは「お名前.com デスクトップクラウド」は「仮想デスクトップ用途向けのWindows VPSに近いサービス」と整理する。
2. 「お名前.com デスクトップクラウド」の責任分界
2.1 サービスのアーキテクチャ
- 提供形態:GMOインターネットが保有するデータセンター内のサーバー上に仮想のWindowsデスクトップを構築し、PC・タブレット・スマートフォンからリモートデスクトップで接続する[3]。
- 割り当て方式:1VMを1利用者に割り当てる[1]。複数の利用者で1台のOSを共有する形態ではない。
- OS・ストレージ:2019年のリニューアルで全プランがSSD、OSはWindows Server 2019となった[2]。その後、2020年3月に「for MT4 ver2.0」、2021年8月に「デスクトップクラウド」が提供開始され[4]、2024年5月には新プランに改められた[5]。現行プランのOSは本ブログでは確認できていない。
- プラン:2019年のリニューアルでFX自動売買向けの「for MT4」が設けられた[2]。ビジネス向けの「for Biz」は2020年3月5日以降の申込分からグローバルIPが標準となった[3][12]。for MT4とfor Bizはいずれも新規受付を終了しており[6][12]、2024年5月30日以降はメモリ容量別の新プラン(StartUp・Standard・Premium)が提供されている[5]。2024年10月にはオプションの「高負荷通知サービス」にMT4/MT5の稼働監視機能が追加されており[7]、MT4/MT5での利用が想定されている。
- 管理系:契約管理のお名前.com Naviと、VMを操作するコントロールパネル。利用者がコントロールパネルからOSを再インストールできることは告知で確認できる[9]。起動・停止などその他の機能は本ブログでは確認できていない。
- 接続方法:リモートデスクトップ(RDP)で接続する。接続時のドライブ共有等の既定設定は公開情報からは確認できない。
注意:提供形態と割り当て方式の根拠は2012年〜2020年の記事・告知であり、2024年5月の新プラン以降も同じ形態かは確認できていない。ハイパーバイザーの種類、ネットワーク分離方式、ディスク暗号化の有無など、内部構成の詳細は公開されていない。
2.2 セキュリティの責任分界
下表の「根拠」列は、告知等で確認できるものを「告知あり」、一般的な考え方から本ブログが想定したものを「想定」、想定のうち一部の場面だけ告知で確認できるものを「想定(一部告知あり)」とする。対象が2019年版のプランに限られる行は、項目名にその旨を記した。
| レイヤー | 主な管理範囲 | 根拠 | 補足 |
| 物理DC・ハードウェア・ネットワーク | GMO | 告知あり | GMOインターネットが保有するデータセンターで運用[3] |
| 共通管理基盤(3章) | GMO | 想定 | 利用者からは直接管理・監視できない層 |
| VMの初期イメージ(共通テンプレート) | GMO | 想定 | 全VM共通の初期設定(初期アカウント、接続設定等)。不備があれば全VMに影響しうる |
| ゲストOS(Windows Server)の緊急のセキュリティ更新の適用 | 利用者 | 告知あり | 2019年8月の告知で、緊急度の高い脆弱性について、利用者にWindows Updateによる早急な適用を求めている[8] |
| ゲストOSの通常の更新 | 利用者 | 想定 | 通常時の更新について告知は確認していない。管理者権限を持つ利用者がVM内で行う運用と想定 |
| OSの提供終了への対応 | 利用者(一部は事業者) | 告知あり | 2022年12月の告知で、提供終了までに利用者自身がコントロールパネルからOSを再インストールするよう求めている。別途、事業者側でサーバー移行を行う場合もある[9] |
| MT4のプリインストール(2019年版for MT4) | GMO | 告知あり | 主要FX会社4社のMT4をプリインストールして提供[2]。新プランでの扱いは未確認 |
| MT4本体の脆弱性修正・更新版の提供 | FX会社・MetaQuotes社 | 想定 | MT4はMetaQuotes社が開発[2]。各FX会社が自社向けに配布する形が一般的 |
| VM上のMT4への更新の適用 | 利用者 | 想定 | 更新版をVM上で適用・再起動する運用は利用者が管理すると想定(プリインストール版を含む) |
| EAの選択・導入・設定・運用 | 利用者 | 想定 | EAは利用者が自分で導入する |
| 取引口座のログイン情報の保存・管理 | 利用者 | 想定 | 無人で自動再開させる運用では、VM内に保存せざるを得ないことが多い |
| データのバックアップ | 利用者 | 想定(一部告知あり) | OS再インストール時は、必要なデータを利用者が事前に保存するよう求められている[9] |
| 接続元の端末(PC・スマートフォン) | 利用者 | 想定 | 端末自体の保護は利用者。ただし、事業者が提供した接続設定を通じて端末に被害が及んだ場合は、この整理がそのまま当てはまらない可能性がある |
注意:2019年版のライトプランは、ブラウザや他のアプリのインストール機能を省き、MT4の稼働に機能を絞っていた[2]。これは製品仕様であり、上表には含めていない。
2.3 VPSとIaaSのセキュリティ上の違い
責任分界の基本はどちらも同じで、違いは利用者が使える防御の道具の多さと、事業者の透明性に出てくる。下表は一般的な傾向であり、本サービスの実装を確認したものではない。VPSでも二段階認証やパケットフィルターを備えるものはある。
| 観点 | VPS(一般的な傾向) | IaaS(AWS・Azure・GCPなど) |
| 管理画面へのログイン | ID・パスワードのみ、または簡易的な二段階認証 | MFAを強制できる、SSO連携、細かい権限設定(IAM) |
| 権限の分割 | 契約者アカウント1つでほぼ全権限 | 人・用途ごとに最小権限を付与できる |
| ネットワーク制御 | 簡易なファイアウォール、またはなし。RDP/SSHが直接公開されがち | VPC、セキュリティグループ、プライベートサブネット、踏み台・VPN経由 |
| 監査ログ | 利用者が見られる操作ログはないか限定的 | 利用者側の管理操作ログ(CloudTrailなど)、フローログ |
| 暗号化・鍵管理 | 事業者任せで利用者から見えないことが多い | ディスク暗号化、利用者管理の鍵(KMS) |
| 秘密情報の保管 | 専用サービスは標準で付かず、VM内のファイルに置く運用になりがち(外部の秘密情報管理サービスをAPIで呼ぶ構成は可能) | Secrets Managerなどの専用サービス |
| 物理的な分離 | 共有ホストが中心 | 専有ホスト・専有インスタンスを選べる |
| 事業者の透明性 | 内部構成や第三者認証の情報が少ない | 責任共有モデル、SOC 2・ISO認証、文書を公開 |
注意:
- IaaSが常に安全というわけではない。機能が多いぶん設定ミス(ストレージの誤公開、アクセスキーの流出など)が起きやすい。
- 事業者側の共通管理基盤が侵害されることは、VPSでもIaaSでも起こりうる。ただし、発生の確率や影響範囲が同じとは限らない。
- IaaSの監査ログに残るのは主に利用者側の操作であり、事業者内部の管理基盤やハイパーバイザーの侵害は利用者のログに残らないことが多い。共通管理基盤の侵害については、VPSでもIaaSでも、事業者の調査と公表に頼る部分が大きい。
3. 共通管理基盤の構造と、侵害されたときに起きること
2章の責任分界は、事業者が共通管理基盤を適切に管理していることを前提に成り立つ。本章では、共通管理基盤の構造と、それが侵害されたときに何が起きるかを整理する。
本ブログでは、ネットワーク機器の3プレーンの考え方を借りて共通管理基盤を整理する。なお、ここでの定義は、SDNでの定義(RFC 7426)とは一致せず、クラウド事業者の用法に近い。以下はGMOの実際の内部構成を示すものではなく、各要素の存在・配置は公開情報から確認できない。
3.1 本ブログでのプレーンの定義
| プレーン | 本書での定義 | 本サービスでの例(一般論、実構成未確認) | 範囲 |
| マネジメントプレーン | 事業者の運用者が、設定・監視・保守のために基盤へアクセスする経路 | 運用者用管理画面、保守用ログイン、監視基盤、運用アカウント | 全体共通 |
| コントロールプレーン | 利用者や管理画面からの指示を受け、VMの作成・停止・再インストール等を実行する仕組み | コントロールパネルの裏側で動くAPIやオーケストレーション | 全体共通(画面は利用者ごと) |
| データプレーン | 実際の処理や通信 | 各VM、Windows、MT4、RDPの通信 | 利用者ごとに分離 |
マネジメントプレーンとコントロールプレーンの違いは、誰の操作を受け付ける経路かにある。前者は事業者の運用者、後者は利用者(およびその指示を受ける管理画面)の操作を受け付ける。クラウド事業者の用語は揺れており、AWSはリソース操作API群を「コントロールプレーン」と呼び、Azureは「管理レイヤー」とも説明するが、本書では上記の定義で用いる。
3.2 プレーン以外の共通要素
- ハイパーバイザー:VMを実行する基盤層。プレーンではないが、全VMに対して特権を持つため、共通管理基盤に含める。
- VMの初期イメージ:全VMに共通して配布される初期設定(初期アカウント、接続設定、導入済みソフトウェア)。操作する仕組みではないが、不備があれば全VMに同じ弱点が及ぶため、共通管理基盤に含める。
- 管理エージェント(存在する場合):VM内で動き、管理側からの指示を受ける仕組み。VM内にあっても事業者側の要素とみなす。なお、本サービスでの存在は確認できていない。
3.3 共通管理基盤が侵害される典型的なパターン
- コントロールプレーンの不具合:利用者向けAPI等の認可不備により、ある利用者が他人のVMを操作できるケース。外部の利用者の立場から攻撃されうる。主な対策は認可設計とAPIの検証。
- マネジメントプレーンの侵害:運用者アカウントや保守経路が侵害され、VMに特権でアクセスされるケース。主な対策は運用アカウントの多要素認証、保守経路の分離、操作の監査。
- 共通要素の不備:VMイメージに共通のアカウントや管理エージェントの脆弱性などにより、全VMに同じ弱点が及ぶケース。主な対策はVMごとの認証情報の個別化と、エージェントの更新管理。
いずれも全VMに影響が及びうる点は同じだが、主な対策の方向が異なるため、区別して考える必要がある。
3.4 共通管理基盤が侵害されたときに起きること
共通管理基盤が侵害されると、攻撃者はVMの外側からディスクを読んだり、VM内でプログラムを動かしたりできる場合がある。このとき、VMにログインするためのWindowsパスワード(認証)は迂回される。データを読まれずに済むか(秘匿)は、ディスク暗号化の有無、鍵の置き場所、VMが稼働中かどうかで変わる。鍵を事業者が管理している場合や、稼働中のVMに入り込まれた場合は、暗号化があっても防げないことがある。本サービスのディスク暗号化の状況は公開されていない。
自動売買に使う取引口座のログイン情報は、無人で自動再開させる運用ではVM内に保存せざるを得ないことが多く、侵害時のリスクになる。
「VM内は利用者の責任」という一般的な分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されると、利用者がVM内で行える対策だけでは防ぎきれない場合がある。また、RDP接続時にドライブやクリップボードを共有していると、VMが侵害された場合に接続元端末へ影響が及ぶ経路になりうる。
3.5 利用者への注意事項
共通管理基盤が侵害されうることを踏まえ、本サービス(および同種のWindows VPS)を利用する際の注意事項を整理する。
3.5.1 管理者としての認識
- 管理する立場であることを認識する:GMOは告知のサービス説明で、本サービスを「面倒な設定などは不要」で「ハイスペックなセカンドパソコン」として使えると案内している[3]。一方で、緊急のセキュリティ更新の適用やOS提供終了時の再インストールは利用者に求められており[8][9]、利用者はWindowsサーバーを管理する立場にある。通常の更新、MT4・EAの更新の適用、保存した認証情報、データのバックアップも、利用者の管理範囲と想定される(2.2)。
- 事業者の告知を確認する:脆弱性への対応やOSの提供終了など、利用者の作業を求める告知が出されることがある[8][9]。登録メールアドレスへの連絡や公式サイトの告知を確認する。
- VMに置くものを絞る:共通管理基盤が侵害されるとVM内の対策は迂回されうるため、「VMに置いたものは読まれうる」と考え、VMに置く認証情報やファイルを必要最小限にする。
3.5.2 取引口座の対策(FX会社が提供している場合)
注意:以下は各FX会社の提供機能に左右される。二段階認証、IP制限、取引用と出金用の認証の分離を提供していない会社もある。
- 口座の保護機能を使う:二段階認証、ログイン元IPの制限、ログイン通知、出金先の固定を設定する。
- 権限を分ける:取引用と出金用で認証を分けられる場合は、出金用の認証をVMに置かない。
- 資金を絞る:自動売買口座には必要な証拠金だけを入れる。
- 異常に早く気づく:約定通知やログイン通知をVMとは別の端末で受け取る。
- Web画面のセッションも切る:FX会社の会員ページ・口座管理画面では、パスワードを変えても既存のログインセッションが残る場合がある。パスワード変更時は全セッションの切断も行う(MT4自体のログインとは別)。
3.5.3 メール・Webアカウントの対策
- 使い回さない:VMに置いたパスワードを他のサービスで使わない。
- 連携・転送設定を点検する:心当たりのない連携アプリ、メール転送設定、ブラウザ拡張機能、登録端末がないか定期的に確認する。
3.5.4 接続元端末の対策
- 共有を絞る:RDP接続ではドライブ・クリップボード等の共有を必要なときだけ有効にする。
- 端末を分ける:可能であれば、取引・出金に使う端末とVPS接続用の端末を分ける。
3.5.5 異常の検知と契約条件の確認
- 自分で異常に気づく:共通管理基盤の侵害は、利用者が見られるログには残らないことが多い(2.3)。異常に気づく手段は、取引口座の通知や取引履歴・残高の確認が中心になるため、定期的に確認する。
- 契約条件を確認する:免責の範囲、補償の条件、データの扱い(解約後のデータ消去を含む)は利用規約で確認する。なお、本ブログは利用規約を確認できていない。別のサービスへ移る場合も、申し込み前に責任分界と条件を確認する。
- 事故の際は公式の案内で動く:事故が起きた場合は、事業者の公式サイトや登録メールアドレスへの連絡で状況を確認する。パスワードや認証コードを尋ねる連絡、「被害金を取り戻す」などの名目で費用を求める連絡には応じない。
4. まとめ
サービスの位置づけ:公開情報からは「仮想デスクトップ用途向けのWindows VPSに近いサービス」と評価できる。VPSがクラウドにあたるかはNIST SP 800-145の定義に照らしてもグレーゾーンにあり、個々のサービス機能で判断する必要がある。
責任分界:物理基盤と共通管理基盤は事業者、ゲストOSの更新、EAの運用、保存した認証情報、データ等は利用者が担うと整理できる。2019年版for MT4ではMT4のプリインストールにGMOが関与し、MT4の更新版の提供はFX会社・MetaQuotes社、VM上での適用は利用者が担う。
共通管理基盤の侵害:「VM内は利用者の責任」という分担は、事業者が共通管理基盤を適切に管理することを前提とする。共通管理基盤が侵害されるとVM内の対策は迂回されうるため、利用者の管理範囲で防ぐという前提そのものが成り立たなくなる。このとき被害を左右するのは、責任分界ではなく、事業者による共通管理基盤の管理と、取引口座側で被害を抑える対策である。
教訓:利用者は、取引口座の保護機能、権限の分離、資金の限定、別端末での通知確認、接続設定の見直しなどで被害を抑えられる。サービスを選ぶ際は、名称ではなく提供機能、責任分界の明確さ、監査ログの有無、事業者の説明と透明性を確認することが重要である。
出典
- [1]@IT 2012年10月10日の記事(仮想デスクトップ市場とお名前.com デスクトップクラウドの紹介) https://atmarkit.itmedia.co.jp/ait/spv/1210/10/news008.html
- [2]お名前.com「お名前.com デスクトップクラウド」フルリニューアルのお知らせ(2019年1月23日) https://www.onamae.com/news/article/10792
- [3]お名前.com FX専用VPS「お名前.com デスクトップクラウド(for Biz/for MT4)」料金改定のお知らせ(2020年3月5日) https://www.onamae.com/news/article/10780
- [4]お名前.com デスクトップクラウド 価格改定のお知らせ(2024年3月ご利用分から。対象プランとして「for MT4 ver2.0(2020/3/5提供開始)」「デスクトップクラウド(2021/8/24提供開始)」を記載) https://www.onamae.com/news/article/10738
- [5]お名前.com デスクトップクラウド 新プラン提供開始のお知らせ(2024年5月30日) https://www.onamae.com/news/article/10734
- [6]お名前.com 新規受付終了サービス:デスクトップクラウド for MT4 https://www.onamae.com/server/closed/dc2-mt4/
- [7]お名前.com デスクトップクラウド 高負荷通知サービス機能アップデート(MT4/MT5の稼働監視、2024年10月17日) https://www.onamae.com/news/article/10724
- [8]お名前.com「Windows Server OSにおける緊急度の高い脆弱性に関するお知らせ」(2019年8月28日) https://www.onamae.com/news/article/11007
- [9]お名前.com「Windows Server 2008 R2 / 2012 R2 をご利用のお客様へ」(2022年12月22日) https://www.onamae.com/news/article/6293
- [10]GMOインターネット「第三者による不正アクセスに関するお詫びとお知らせ」(第1報、2026年10月21日) https://www.onamae.com/news/article/11584
- [11]NIST SP 800-145 The NIST Definition of Cloud Computing https://csrc.nist.gov/pubs/sp/800/145/final
- [12]お名前.com 新規受付終了サービス:デスクトップクラウド for Biz https://www.onamae.com/server/closed/dc2-biz/
以上
