2026年9月より不正アクセス・情報漏えい事案が相次いでいますが、某インターネット企業の仮想専用サーバー（VPS）サービスへの不正アクセスは「認証」と「認可」のタイムラグの構造的な課題を浮き彫りにしました。エンドユーザの金銭被害に関する保証についても議論されることになると思いますが、攻撃経路、二重脅迫の対応策、インフラ設計の盲点、さらに、2026年10月1日より施行された「能動的サイバー防御法」の発動を政府へ要請した初めての事例として我々が新たに学ぶべき事例のひとつだと考えています。
1. インシデントの概要と攻撃ベクター分析
2026年10月に表面化した某インターネット企業（G社）における不正アクセス事案は、単なる一企業のクラウドサービス障害にとどまらない深刻な波紋を広げました。仮想専用サーバー（VPS）サービス上で顧客が運用していた金融取引環境が直接的な攻撃対象となり、実際の金銭的被害に直結した本件は、BtoBおよびBtoC向けにWeb・クラウドインフラを提供するすべての事業者やインフラエンジニアに対して、極めて重い警鐘を鳴らしています。従来の「境界型防御」や「事後対応型セキュリティ」の限界が露呈した本インシデントの攻撃経路と初動対応を客観的・構造的に解剖することは、現代の堅牢なインフラ基盤を構築・運用するうえで不可欠なプロセスです。
1.1 時系列分析と被害規模の全体像
本事案は、2026年10月19日に利用者からの問い合わせを受けたことをきっかけに調査が始まり、短期間のうちに全サーバー停止、警察相談、そして被害補償と国家レベルの新制度活用要請に至る急速な展開を見せました。
以下は、公表された情報を基に、発覚から対応措置までのタイムラインと技術的影響を整理した比較表です。
| 日付 | 発生事象 | 事業者の対応措置 | 技術的影響・被害の概要 |
| 2026年10月19日 | 利用者より異変に関する問い合わせを受領 | 事態把握のため内部調査を開始 | システム内部での異常動作の検知と確認フェーズ |
| 2026年10月20日 | 一部利用者のサーバー環境で第三者による不正プログラム設置を確認 | 新規利用申し込みおよびコントロールパネルの機能を停止、緊急メンテナンスを実施 | 攻撃者による不正プログラムの常駐およびシステム侵入が確実視される |
| 2026年10月21日 | 被害拡大防止の観点から深刻度を再評価 | 04:00より全プランのサーバー（2万6,739件）を順次停止、外部ネットワーク接続を遮断（第1報公表） | VPSサービス全停止。保存情報（認証情報等）が第三者に閲覧・持ち出された可能性が浮上 |
| 2026年10月22日 | 取引口座における不正操作の報告が相次ぐ | 警察当局（サイバー犯罪対策部門）へ相談・全通信記録等を提出、捜査協力を開始（第2報公表） | 刑事事件としての捜査プロセスへ移行 |
| 2026年10月23日 | パスワード変更後も不正取引が継続するリスクを特定 | 利用者へパスワード変更に加えログオフ（セッション切断）を要請。主要証券・FX会社へアクティブセッション強制切断を要請（第3報公表） | 認証とセッション管理の解離による二次被害のリスクが顕在化 |
| 2026年10月24日 | 調査によりシステム上のセキュリティ問題と顧客情報の外部流出、金銭要求脅迫を確認 | 全顧客へ一律5,000円のお見舞金支給および不正取引の実質損失補償を発表。既存基盤の再開断念と新基盤リプレイス（6ヶ月無償）を決定。政府へ「能動的サイバー防御」発動第1号を具申（第4報公表、第5報公表） | 既存VPS基盤の完全廃止、二重脅迫の公表、および官民連携による安全保障枠組みへの移行 |
最大2万6,739件のサーバー環境が影響対象となり、システム内に保存されていた口座ログイン情報等の外部持ち出しによって、金融資産の直接的な毀損という前例のない被害へと発展しました。
1.2 FX自動売買システムの環境特有の脅威モデル
不正アクセスのあったサービスは、リモートデスクトップ接続を介して仮想的なWindowsPC環境を運用できるVPSサービスであり、特に外国為替証拠金取引（FX）の自動売買ソフトを24時間365日ノンストップで稼働させる用途で広く利用されていました。この運用構造には、極めて特異な脅威モデルが存在します。
- 認証情報の常時保持と自動入力: 自動売買を実行するため、利用者は各種証券会社やFX会社のアカウントログイン情報（ID・パスワード）をVPS上のソフトウェア内に保存・保持させています。
- 稼働の継続性と無人運用: 24時間稼働が前提であるため、利用者が常時画面を監視しているわけではなく、不正アクセスや異常な注文が行われても即座に気づきにくい環境にあります。
攻撃者は、VPS基盤側に存在していた「セキュリティ上の問題（脆弱性）」を突いてシステム内部へ侵入し、各仮想環境内に保管されていた金融機関のログイン認証情報を窃取（Kill Chainの成立）しました。攻撃者は取得した認証情報を用いて、外部の証券会社やFX会社の口座へ第三者になりすましてアクセスし、不正な注文を勝手に実行して顧客の残高を激しく毀損させたのです。実際にSNS等では多額の損失被害報告が相次ぎ、インフラ基盤の侵害が直接的に利用者の現実資産の掠奪へ繋がるという極めて凶悪なインパクトをもたらしました。
1.3 「セッション維持」がもたらした二次被害のメカニズム
本事案における技術的分析において最も特筆すべきは、「パスワードの変更だけでは不正取引を止められなかった」という認証・認可およびセッション管理の解離問題です。
多くのWebサービスや金融取引システムでは、利用者が一度ログインに成功すると、サーバー側からアクセストークンやセッション識別子が発行され、一定期間は再ログインなしで取引が継続できる仕組みになっています。今回、事業者が10月21日にサーバーを停止し、利用者に認証情報の変更を呼びかけたものの、攻撃者がサービス停止前にすでにログイン認証情報を取得し、証券会社のシステム上で「ログイン済みの有効なセッション」を確立していた場合、利用者が後からパスワードを変更しても、既存のセッションが無効化（Invalidate）されない限り、攻撃者はそのまま取引画面を操作し続けることが可能でした。
技術的なアーキテクチャの観点から言えば、パスワード変更イベントが既存のJWT（JSON Web Token）のブラックリスト登録・Revocation処理や、Redis等のインメモリDBに格納されたセッションキーの即時破棄、あるいはOAuth/OIDCにおけるToken Revocation Endpointのキックへと即座に連動していなかったことが、被害を継続させた原因です。この「認証（パスワード変更）」と「認可/状態保持（セッション維持）」のタイムラグと構造的課題により、事業者側は単なる自社サーバーの停止措置にとどまらず、主要な取引所や証券会社各社に対して「本サービス経由のアクセス遮断」や「稼働中全アクティブセッションの強制切断（ログオフ）」を緊急要請せざるを得ない事態へと追い込まれました。
このように、単一のインフラの脆弱性が外部の金融サービスやセッション維持機構と複雑に絡み合い被害が拡大した背景には、攻撃者が事業者に対して突きつけた悪質な脅迫と、それに対する事業者の決断が深く関係しています。
2. 攻撃者の脅迫手口と事業者側の意思決定（二重脅迫とインフラ全面停止）
現在におけるサイバー攻撃、特に重要インフラやクラウド基盤を標的とした攻撃では、データの暗号化だけでなく情報の暴露や事業妨害を盾に金銭を要求する「二重脅迫（ダブルエクストーション）」が猛威を振るっています。危機的状況下において、事業者がいかなる意思決定を下し、リスクを排除しようとしたかを検証することは、BCP（事業継続計画）の観点からきわめて重要です。
2.1 二重脅迫（恐喝）の実態と金銭要求拒否のロジック
本事案において、攻撃者とみられる人物はG社に対し暗号資産等による金銭の支払いを要求すると同時に、以下のような多角的な脅迫（二重・多重脅迫）を突きつけました。
- 金融口座での不正操作継続: 国内外70を超える証券会社・FX会社に開設された顧客の取引口座において、不正な注文による残高毀損を継続するという主張。
- 顧客情報およびPC情報の不正公開・追撃: 本サービスおよびサービスに接続された顧客のPCに関する情報の不正公開、ならびに追加のランサムウェア攻撃の実行予告。
- 事業者内部情報の暴露: G社グループの内部システムや運用体制等に関する情報の不正公開予告。
これに対し、同社は「攻撃者からの金銭要求には一切応じない」方針を明確に断言しました。身代金を要求する攻撃者と取引を行っても、盗まれたデータが確実に削除される保証や、将来的な不正利用・再攻撃が防止される保証は技術的にも運用上も存在しません。金銭の支払いは反社会的組織への資金供与にしかならず、根本的な解決にならないという観点から、要求を拒絶し警察当局へ全証拠を提出して刑事捜査に全面的に協力する決断を下したことは、セキュリティ運用上、非常に妥当な判断と評価できます。
2.2 「既存環境の再開断念」と新環境リプレイスのアーキテクチャ的評価
サービス復旧における事業者の判断として最も決断力を要したのが、「侵害された現行システム基盤の再開を全面的に断念し、独立した新クラウド基盤へ刷新する」というアーキテクチャ上の選択です。
一度ハイパーバイザーレベルや管理基盤内部にまで侵入され、不正プログラムが設置・展開されたシステム環境においては、表面上のマルウェアを削除するだけでは不十分です。攻撃者が潜伏用のバックドアや永続化メカニズム（Persistence）をシステム深部に残している可能性を完全に否定することは極めて困難だからです。クリーンアップのみで現行基盤を再開した場合、未知の潜伏手法によって再びシステムが全域崩壊する潜在的リスクを抱え続けることになります。
したがって、既存の環境を「完全に汚染されたもの」として破棄し、設計からセキュリティ構成を見直した独立した新クラウド基盤へユーザーをリプレイス（移行希望者には6ヶ月間無償提供）するという決定は、インフラ運用における「クリーン・リセット原則（Clean Reset Principle）」を忠実に実行したものであり、残留リスクを根本から排除して信頼を再構築するための技術的に極めて合理的な判断といえます。
2.3 被害発生時の事業者による損害補償・お見舞金の設計方針
大規模インシデントにおける顧客対応として、同社が提示した補償方針は以下の2段階で設計されました。
- 一律お見舞金の支給: 金銭被害の有無にかかわらず、現行サービスを利用している全顧客に対して一律5,000円のお見舞金を支給。
- 不正取引による実質損失の補償: 本件の不正アクセスに起因して発生した取引の実現損失（差損および取引手数料等）を補償。
損害補償の構造としては、利用客に対し不審取引の客観的記録の提出を求めるとともに、まずは取引先の証券会社・FX会社へ事情を説明して取引取り消しや返金の相談を行うよう要請しています。取引所等から返金が行われた場合はその額を控除した差額を同社が補償し、返金に応じてもらえない場合でも、同社の調査に基づき確定した実損額を全額補償するというスキームが構築されました。
ここでセキュリティ運用上、極めて重要な注意点として事業者が周知したのが「補償手続きに乗じた二次フィッシング詐欺への対策」です。同社は、本人確認や被害調査の過程で利用者に資料提出を求める際にも、「事業者側から通常のログインパスワードや取引暗証番号をお尋ねすることは絶対にない（取引確認のためにMT4/MT5等の『閲覧専用パスワード/インベスターパスワード』の提示を依頼する場合を除く）」という厳格な設計方針を提示しました。大規模インシデント直後のお見舞金・補償手続きを騙って暗証番号を騙し取ろうとするフィッシング攻撃が横行するため、手続き上の入力項目を閲覧専用権限等に限定する防御設計を明示することは、顧客保護の観点から必須のプロセスです。
このような事業者の危機対応とアーキテクチャ刷新の判断を踏まえ、次にクラウド／VPSインフラを設計・運用するエンジニアが自社環境へ還元すべき具体的な技術的教訓について整理します。
3. クラウド・VPS事業者が学ぶべきアーキテクチャ上の技術的教訓
一つのインフラ基盤の破綻が2万6千台以上の仮想サーバーへ波及した本件の教訓は、クラウドやVPSを設計・運用するエンジニアにとって、自社の予防的ガードレール（Preventive Guardrails）を即座に見直すための教訓に満ちています。
3.1 ホスト／ゲスト間およびマルチテナント間の強力な隔離設計
マルチテナント環境を提供するVPSやクラウドインフラにおいて、最も警戒すべきは1つのテナントやハイパーバイザー（ホスト）側の脆弱性が、システム全体や他テナントへ及ぶ「ラテラルムーブメント（水平展開・横移動）」です。
- Hypervisor Escape（ハイパーバイザー回避）の防止: ゲストOSからホストOSの制御権限を奪取するHypervisor Escape攻撃を防ぐため、ハイパーバイザーの最小化および最新パッチの適用を徹底する必要があります。また、より軽量かつ強力な隔離境界を提供するマイクロVM技術（例: AWS Firecracker、gVisor等）をアーキテクチャに採用することも極めて有効な選択肢です。
- ネットワークのマイクロセグメンテーション: テナント間やホスト管理ネットワーク間の不要な通信を徹底的に排除するため、後述するZero NetworksやNSX、Calico等を導入してマイクロセグメンテーション（MicroSegmentation）を構築します。これにより、万が一特定のテナントが侵害された場合でも、C2通信（Command & Control）や他テナントへの横展開を物理的・論理的に隔離・遮断することが可能となります。
- テナント間の完全孤立化: 共通の管理コンソールや認証APIが存在する場合、単一のコントロールパネルの脆弱性が全テナントの制御権限奪取に繋がらないよう、テナントごとの権限分離（PoLP: 最小権限の原則）をアーキテクチャレベルで強制しなければなりません。
3.2 認証情報保護・アクセス制御・セッション管理の厳格化
インフラ基盤およびその上で動くアプリケーションの双方が満たすべき、アクセス制御とセッション管理の技術要件は以下の通りです。
- 多要素認証（2FA/MFA）の強制: 管理コンソールやVPSへの接続経路に対して、単一のパスワード認証を排除し、2FAを必須化すること。
- アクセス元IP制限と暗号化ストレージ: 管理機能へのアクセスを信頼されたIPアドレス（固定IP等）に制限するとともに、システム内に保持される一切の資格情報・APIキー・パスワードを暗号化ストレージ（KMSやKey Vault等）で保護すること。
- 確実なセッション失効（Revocation）ロジックの実装: ユーザーがパスワードを変更した際には、単にDB上のパスワードハッシュを更新するだけでなく、Redis等のインメモリデータストアに存在する該当ユーザーのセッションキーを全削除するイベントを発火させる必要があります。また、JWTを利用している場合はトークン識別子（jti）をRevocation List（ブラックリスト）へ即時登録・検証するロジックや、OIDC（OpenID Connect）のRevocation Endpointをキックする仕組みを組み込み、アクティブセッションを確実に無効化しなければなりません。
- 補償・サポート運用における認証情報の分離設計: 2.3節で触れた通り、サポートや損失補償などの運用フローにおいて、システム側が平文のログインパスワードや暗証番号の提出を要求する設計を絶対に作らないこと（閲覧専用権限・トークンのみで完結させる設計にする）。
3.3 エンジニアが即座に活用できる「コピペ・点検用チェックリスト」
自社のVPS、クラウド環境、あるいは顧客向けに構築したインフラの設定を点検・強化するために活用できる具体策と実装例を付け加えたチェックリストです。
====================================================================
クラウド／VPS・サーバー環境 セキュリティ緊急点検チェックリスト
====================================================================
【サーバー / VPS設定】
[ ] 1. 管理画面・SSH・RDP等の接続元IPアドレス制限（Allowlist）の設定
（推奨設定/実装例: iptables/nftables/Security Groupでの固定IP制限、VPN経由限定化）
[ ] 2. 不要なポート（未開放にすべきサービス）のファイアウォール遮断
（推奨設定/実装例: Nmap/OpenVAS等による外部露出ポートの定期自動スキャン）
[ ] 3. OSおよびミドルウェアのセキュリティパッチ自動更新・定期適用
（推奨設定/実装例: unattended-upgradesの設定、Stage/Prodの段階的自動適用Pipeline）
[ ] 4. デフォルト管理ポート（22, 3389等）の変更および不要プロトコルの無効化
（推奨設定/実装例: RDP/SSHポート番号変更、Telnet/HTTP等の平文通信の全面禁止）
【認証・セッション管理】
[ ] 5. 管理コンソールおよびVPS接続における多要素認証（2FA/MFA）の強制
（推奨設定/実装例: TOTP/FIDO2パスキーの必須化、バイパス用バックアップコードの管理）
[ ] 6. パスワード変更時の「全アクティブセッションの強制切断・トークン無効化」仕様確認
（推奨設定/実装例: DB/Redisのセッション破棄イベント発火、JWTブラックリスト（jti）検証）
[ ] 7. 複雑なパスワードポリシーおよびパスワード使い回し防止の設定
（推奨設定/実装例: 16文字以上、HaveIBeenPwned API連携による流出パスワードブロック）
[ ] 8. 暗号化ストレージによる認証情報・APIキーの保護と平文放置の禁止
（推奨設定/実装例: AWS KMS、HashiCorp Vault、Azure Key Vaultの活用）
【運用・監視・ログ】
[ ] 9. 改ざん不可な外部ストレージへのアクセス・操作ログ長期転送・保管
（推奨設定/実装例: S3 Object Lock（WORM機能）、CloudWatch Logs経由のリアルタイム転送）
[ ] 10. 不審なプロセスや未知の実行ファイルの設置を検知・遮断する定期スキャン
（推奨設定/実装例: 次世代エンドポイントセキュリティ（Deep Instinct）、EDRによるファイルレス攻撃監視）
[ ] 11. Primary環境から孤立させた耐改ざん性バックアップ（イミュータブルバックアップ）の確立
（推奨設定/実装例: ゼロトラストデータ保護（Rubrik）、エアギャップバックアップ、別リージョン・別アカウントへの非同期バックアップ）
====================================================================
個々のインフラにおける防衛策の強化と並行して、現代のサイバー防衛は民間単独の枠組みを超え、国家レベルの新制度「能動的サイバー防御」との連携という新しい局面へと移行しつつあります。
4. 「能動的サイバー防御」制度の技術的・運用インパクトと今後の考慮事項
日本国内において、2026年10月1日より「サイバー対処能力強化法」（正式名称：重要電子計算機に対する不正な行為による被害の防止に関する法律）および同整備法の一部が施行され、「能動的サイバー防御（Active Cyber Defense）」の運用が正式に開始されました。G社が自社インシデントにおいて本制度の「発動第1号」としての適用を政府に緊急要請したことは、民間企業のセキュリティ運用およびエンジニアの責務に対する考え方を根本から変えるエポックメイクな出来事となりました。
4.1 「能動的サイバー防御（Active Cyber Defense）」の制度構造と要件
能動的サイバー防御とは、国や基幹インフラ等に対する重大なサイバー攻撃に対し、被害が拡大・深刻化する前に、警察や自衛隊等の国家機関が主導して攻撃者のインフラや侵入経路を特定・追跡し、アクセス・無害化（無効化）措置を講じる安全保障上の枠組みです。
- 制度の要件と官民の明確な役割分担: 本制度は、民間企業や被災事業者が要請を出せば自動的に発動される仕組みではありません。G社側が「発動第1号」として政府へ具申・要請を行ったものの、実際の適用可否や無害化措置の実施判断は、法的要件や国家安全保障上の観点に基づき、政府（国）が主体となって個別に判断・決定する厳格な枠組みとなっています。
- 従来の境界を超えた防御: 民間企業単独の「自社ネットワーク内の防衛」という限界を超え、国境を跨いで活動する攻撃基盤に対して国家レベルで先手を打つという、安全保障と一体化したセキュリティ概念です。
4.2 民間事業者・エンジニアに求められる官民連携と「フォレンジック準備性」
G社が攻撃検知後、直ちに警察へ通信記録等の全証拠を提出し、政府へ調査ログや侵害情報を提供したように、政府や捜査機関が能動的サイバー防御の発動検討や攻撃基盤の特定を行うためには、民間事業者側からの精査された一次データの提供が不可欠となります。
ここでインフラエンジニアに強く求められるのが「フォレンジック準備性（Forensic Readiness）」です。
- 改ざん不可なログの長期保管: 攻撃者が侵入後に自身の足跡（ログ）を消去・改ざんすることを想定し、ログを即時に改ざん不可能な外部の専用ストレージ（Write Once Read Many: WORM機能等）へリアルタイム転送・長期保存する構成が必要です。
- ネットワークトラフィックとIOCの迅速抽出: 侵入経路やC2（Command and Control）サーバーとの通信を特定するため、ネットワークフローやIOC（侵害指標: Indicators of Compromise）を迅速に抽出・共有できる分析体制を平常時から整えておかなければなりません。
4.3 自動運用環境における多層防御（Defense in Depth）とゼロトラスト原則
Botや自動売買プログラム、あるいはAPI連携によって24時間無人稼働する「自動運用環境」においては、境界防御（外側を固めれば内側は安全という考え方）はもはや機能しません。システムの一部が侵害されることを前提とした「ゼロトラスト（誰も信じない・常に検証する）」モデルへの完全移行が必要です。
- 多層防御（Defense in Depth）の徹底: ネットワークの分離、最小権限のアクセス制御、エンドポイントの挙動監視（EDR）、データの暗号化、そしてセッションの厳格なライフサイクル管理など、単一の防御壁に頼らない多層的なセキュリティガードレールを張り巡らせることが、金融資産や重要データを扱うモダンインフラの絶対条件となります。
新たな制度的枠組みの誕生とゼロトラスト思想の必要性を確認したうえで、本稿のまとめとしてエンジニアが目指すべき運用の姿を総括します。
5. まとめ：自動運用環境における多層防御とゼロトラストの必要性
本不正アクセス事案は、VPS基盤の脆弱性、認証・セッション管理の課題、自動売買環境特有の金銭的リスク、そして攻撃者による二重脅迫と、現代のクラウドインフラが直面するあらゆるリスクが凝縮された象徴的なケースでした。インフラを預かるエンジニアや事業者は、単に「自社のシステムを止めない」ことだけを目指すのではなく、万が一の侵害時においても被害を局所化し、顧客の資産と信頼を守り抜く堅牢なアーキテクチャを構築しなければなりません。
5.1 本事案から得られた最重要テイクアウェイの整理
- システム固有の脅威モデルとセッション管理の徹底: 自動運用ツール（MT4/MT5等）が認証情報を保持する特殊リスクを正しく評価し、パスワード変更時にはRedis等のセッション破棄やJWTブラックリスト化を連動させ、関連する全アクティブセッションを即座に強制無効化する連携ロジックの実装が不可欠である。
- クリーン・リセット原則による徹底的なリスク排除: 深刻な侵害を受けた基盤は安易にクリーンアップ再開を目指すのではなく、潜在的なバックドアリスクを断ち切るために「既存基盤の廃棄と独立した新環境へのリプレイス」を選択する断念の決断力が必要である。
- フォレンジック準備性と「能動的サイバー防御」時代への適合: 警察や政府との官民連携・捜査協力を円滑に行うため、改ざん不能なログの保存やIOC抽出体制（フォレンジック準備性）を平常時から整え、ゼロトラスト思想に基づく多層防御を確立しなければならない。
5.2 自社環境のゼロトラスト化に向けて
フロンティアAIの進化とともに、サイバー攻撃の手口はますます高度化・凶悪化し、クラウドインフラを支えるエンジニアの皆様が背負う責任と課題は日々大きくなっています。しかし、リスクを恐れてクラウドや自動化の推進を止めるのではなく、正しく脅威を構造化し、適切な予防策とガードレールを実装していくことこそが、エンジニアリングの本質です。
SCSKは、フロンティアAI時代は、ゼロトラストの原則である「侵入は避けられない（Assume Breach）」を前提としたサイバーレジリエンスの実装が最も重要であると考えています。フロンティアAIレディの「3層防御モデル」、特にランサムウェア被害で、最大の課題「ラテラルムーブメント（水平展開・横移動）」を阻止する具体的なソリューションとして 次世代マイクロセグメンテーション Zero Networks を強くお勧めしております。
Zero Networks は、サーバ・クライアントといったホスト単位でネットワーク分離（セグメンテーション）するのはもちろんのこと、特許技術を用いて管理ポート（RDP/SSH等）をデフォルトで閉鎖し、ジャストインタイム（Just-In-Time：JIT）で多要素認証（MFA）を適用することが可能です（≒特権ID管理）これまでのレガシーマイクロセグメンテーションとは全く異なる”完全エージェントレス型”で、通信可視化からAIによるポリシー自動生成が可能なため短期間の導入が可能です。
すでに多くの引き合いをいただいておりますが、Zero Networks に興味をもたれた方は、ぜひお問い合わせください。
最後に、2026年11月11日 Zero Networks と、マイクロセグメンテーションと組み合わせることで完全なゼロトラストを実現する SASE（Secure Access Service Edge、サッシー）、これまでのウィルス対策ソフト・EDRと異なり、AI ディープラーニング（深層学習）にて非常に高い検知率を誇る次世代エンドポイントソリューション、そして攻撃者が侵入後に真っ先に狙うバックアップデータを保護し、確実な復旧を早期に実現するためのゼロトラストデータ保護ソリューションなど、多層防御とゼロトラストを実現する4つのベスト・オブ・ブリードのセキュリティソリューションをご紹介するオンラインセミナー（無料）を開催しますので、ぜひご参加ください。
最後までお読みいただき、ありがとうございました。