軽量かつ攻撃表面（アタックサーフェス）が少ないため、コンテナやマイクロサービスアーキテクチャの標準ベースイメージとして圧倒的支持を集めてきたAlpine Linuxですが、2026年11月5日、その足元を大きく揺るがす極めて深刻な脆弱性が公表されました。OpenSSHと標準Cライブラリ「musl libc」の複合的な挙動に起因する認証バイパス脆弱性、通称「sshole（CVE-2026-123158）」です。本脆弱性は、正規パスワードや秘密鍵を所有していなくても、特定の長さを持つパスワードを送信するだけで、本来パスワードログインが禁止されているアカウント認証を通過できてしまうという致命的な性質を持っています。
単なる脆弱性ニュースのなぞり書きでは、現場での実務には役立ちませんので、Cライブラリ内部の比較ロジック、/etc/shadow の仕様差分、攻撃成立条件の整理、スキャナーの偽陰性を生む技術的ギャップ、そして現場のインフラエンジニアやSREが今すぐ実行すべき対策と運用の落とし穴までを解説します。
1. エグゼクティブサマリー
CVE-2026-123158（sshole）は、Linux環境で広く用いられているOpenSSHの認証照合ロジックと、Alpine Linux等で採用されている軽量Cライブラリ「musl libc」のエラー処理仕様との間で発生する特殊な相互作用を突いた認証回避の欠陥です。※Debian, Ubuntu, RHEL等の「glibc」環境では発生しません。
本脆弱性の基本スペックおよび概要は以下の通りです。
- CVE ID / 通称: CVE-2026-123158 / sshole（または
*sshole） - 深刻度: CVSS v3.1 スコア 8.1（High）［Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H］
- 影響の概要: 攻撃者が257〜1,024バイトの長大パスワードを送信することで、
/etc/shadowのパスワードフィールドが「*」（パスワード認証未設定・無効化）に設定されているアカウントに対し、パスワード照合ロジックを偽装通過してSSHログインが成功してしまう欠陥。 - 影響を受ける主要環境: Alpine Linux（デフォルト構成の
openssh-server）、Buildroot、Yocto（TCLIBC=musl構成）、OpenWrt（デフォルトのDropbearではなくOpenSSHを導入している場合）等、musl libcを基盤とし、PAMを用いずにOpenSSHを運用している環境。
【緊急アラート：公表から9時間以内に野良攻撃（In-the-Wild）を観測】
2026年11月5日の脆弱性公表からわずか9時間以内に、ハニーポット環境（Previdian /Aviatrix等の報告）において実際の悪用試行および root 権限奪取が観測されました。フロンティアAI時代においては、従来の脆弱性のように「数日間の検討猶予」は存在しません。
なぜ今すぐ対応が必要なのか？
Alpine Linuxは、DockerやKubernetesなどのコンテナ環境におけるデファクト標準のベースイメージとして、またAWSやAzure上のクラウドイメージ（tiny-cloud 等）として世界中で膨大に展開されています。
公表直後から、インターネット全域を対象とした自動化スキャンおよび攻撃ボットの巡回が開始されています。外部に対してSSHポート（TCP 22番）を露出しているコンテナやサーバーが存在し、後述する5つの前提条件を満たしている場合、正しい資格情報を持たない第三者によって即座に侵入される危険性があります。
インフラエンジニアおよびSREは、大至急影響対象の抽出、ワークアラウンドの適用、または修正パッケージのデプロイを完了させなければなりません。
2. なぜ起きるのか？根本原因（Root Cause）の深掘り
本脆弱性の極めて興味深い点は、OpenSSHまたは musl libc のどちらか片方に「明確なプログラム上のバグ」が存在するわけではないという点です。セキュリティ向上を目的とした過去の改修やライブラリの仕様が、10年の時を経て複合的に衝突した結果生じた構造的欠陥です。
技術的メカニズムの三位一体構造
本脆弱性は、以下の3つの独立した仕様・ロジックが連鎖することによって引き起こされます。
[1] musl libc の crypt() 仕様 (2012年〜)
・256バイト超の入力時、CPU枯渇攻撃(DoS)防止のためエラー記号 "*" を返却
┼
[2] /etc/shadow の慣行仕様
・パスワード無効化アカウントのハッシュ欄に "*" を格納
※ Note: ロック状態を意味する "!" とは明確に挙動が異なる
┼
[3] OpenSSH のソルト借用ロジック (2016年〜 / PAM非依存時)
・CVE-2016-6210(ユーザー名列挙攻撃)対策のため、ハッシュ値のない
無効化アカウントに対しても他アカウントのソルトを借用して crypt() を計算・比較
║
▼
【衝突の瞬間】長大パスワード送信時、crypt() の戻り値 "*" と /etc/shadow の "*" が一致し認証通過！
- musl libc の
crypt()仕様（2012年導入）: musl libc のcrypt()関数（SHA-256 / SHA-512ハッシュ計算）は、過大な文字列入力によるCPU資源枯渇（DoS）攻撃を防ぐため、入力パスワード長が256バイトを超えるとハッシュ計算を打ち切り、エラーを示す固定文字列「*」を返却するように設計されています。 /etc/shadowの仕様差分（「*」と「!」の違い）: Linuxシステムでは、パスワードが未設定または鍵認証専用となっているアカウントの/etc/shadowパスワード欄に「*」を記録する慣行があります。これは本来「どんなパスワードを入力してもハッシュが絶対に一致しない状態（パスワード認証の無効化）」を意図しています。 ここで重要なセキュリティ境界線として、アカウントを明示的にロックした状態を表す「!」（または!*）が設定されているアカウントは、本脆弱性の影響を受けません。crypt()のエラー戻り値*と shadow 内の!は一致しないためです。エンジニアがアカウント棚卸しを行う際は、この「*（未設定）」と「!（ロック中）」の違いを正確に把握しておく必要があります。- OpenSSH のソルト借用ロジック（2016年導入 / PAM非依存時）: 2016年、OpenSSH開発チームはユーザー名の存在有無によって応答時間が変化するタイミング攻撃脆弱性（CVE-2016-6210）に対処しました。PAMを使用しない内部認証処理において、存在しないユーザーやパスワードが無効化されているユーザー（ハッシュ欄が
*）に対しても、応答時間を均一化するためにシステム上の他アカウントから有効なソルト（$5$や$6$）を借りてcrypt()を計算し、その結果と shadow の値を文字列比較する設計を採用しました。
衝突の瞬間
攻撃者が /etc/shadow の値が * であるアカウントに対し、257バイト以上のパスワードを送信すると、OpenSSHは他アカウントのソルトを借用して musl の crypt() を呼び出します。musl は256バイト超の入力に対してエラー文字列「*」を返します。するとOpenSSHは、**crypt() の戻り値「*」と/etc/shadow に保存されている「*」**を文字列比較し、「完全一致した」と判定して認証を許可してしまうのです。
環境固有の背景：なぜ glibc や PAM 環境では発生しないのか
本現象はすべてのLinux環境で発生するわけではありません。
| コンポーネント / 設定 | glibc系（Debian, Ubuntu, RHEL等） | musl libc系（Alpine Linux等） |
crypt() の挙動 |
長大入力時も標準的なハッシュ計算または別様のエラー処理（NULL等） | 256バイト超でエラー文字列「*」を返却 |
PAM認証（UsePAM yes） |
PAMモジュール側で安全に遮断 | PAMモジュール側で安全に遮断 |
OpenSSH独自照合（UsePAM no） |
発生しない | * 同士の文字列一致により認証回避が成立 |
DebianやUbuntu、RHELなどで標準採用されている glibc 環境や、openssh-server-pam パッケージ等を用いて PAM（Pluggable Authentication Modules）経由で認証を行う構成（UsePAM yes）では、OpenSSH内部のソルト借用・文字列比較ロジックを通らないか、crypt() のエラー処理メカニズムが異なるため、本脆弱性は発生しません。
発見の経緯と10年間の盲点：開発者への寄り添いとAIの示唆
この脆弱性を生み出す仕様の組み合わせは2016年のOpenSSH改修時点で成立しており、約10年間にわたり見落とされていました。
しかし、これを「開発者の不注意」や「単純な設定ミス」と責めるべきではありません。2016年のソルト借用ロジック導入は、CVE-2016-6210というユーザー名列挙の側波帯攻撃からユーザーを守るための、きわめて高度で誠実なセキュリティ修正でした。一方でmusl libcの制限も、CPU枯渇攻撃からシステムを守るための合理的な設計方針でした。二つの正当な防御策が、Linuxの古い歴史的慣行（*）を介して結びついてしまった点に、システムアーキテクチャの根深い難しさがあります。
本脆弱性を発見したセキュリティ研究者の Özgün Kültekin 氏（Wakefield）は、glibc / musl libc、PAMの有無など多種多様な環境を構築し、複数のAIエージェントを活用して約17,600回に及ぶ自動異形ログイン検証を実施しました。人間の静的コード解析や従来の単体テストの盲点を、フロンティアAIによる網羅的かつ自律的な実地検証が打ち破った歴史的事例と言えます。
3. 攻撃成立に必要な5つの前提条件
無用なアラート対応や現場の混乱を避けるため、本脆弱性がどのような条件で発動するのかを正確に把握しておく必要があります。
本脆弱性は、以下の5つの条件が「同時にすべて」揃った場合のみ攻撃が成立します。1つでも条件が欠けていれば攻撃は成立しません。
攻撃成立の5条件チェックリスト
| 項目（条件） | 詳細な技術的要件と確認ポイント |
| 1. Cライブラリ | システムが musl libc を使用していること（glibc は対象外）。 |
| 2. PAMの非運用 | OpenSSHがPAM非依存でビルド・運用されていること（Alpine標準の openssh-server、または UsePAM no 設定）。 |
| 3. パスワード認証の有効 | sshd 設定で PasswordAuthentication yes が有効であること（デフォルト値）。 |
| 4. 標的アカウントの存在 | /etc/shadow のパスワード欄が 「*」 であるアカウント（alpine ユーザー、パスワード未設定の鍵専用ユーザー等）が存在すること（※「!」でロックされたアカウントは対象外）。 |
| 5. ソルト提供用アカウントの存在 | 同一システム上に、SHA-256（$5$）またはSHA-512（$6$）の有効なパスワードハッシュを持つローカルアカウントが少なくとも1つ存在すること。 |
特筆すべきリスクシナリオ：Official Alpine Cloud Images（tiny-cloud）と root 昇格パス
特にクラウド運用者が警戒すべきなのが、Alpine Linux の公式クラウドイメージ「tiny-cloud」（バージョン 3.18.11 〜 3.24.3）の挙動です。
- 初期状態（潜在的危険）:
tiny-cloudイメージには標準でalpineユーザーが存在し、/etc/shadowのパスワード欄は「*」になっています。さらに、このalpineユーザーはdoasコマンドを介してパスワードなしで root 権限を実行できる設定となっています。デプロイ直後は「条件5（別アカウントの有効なハッシュ）」が存在しないため、すぐには攻撃できません。 - 条件成立の瞬間: 管理者が運用保守のために別のアカウントを作成し、ローカルパスワード（
$6$等）を設定した瞬間、システム内に有効なソルトが生成され、条件5が満たされます。 - 特権昇格攻撃の成立: 外部の攻撃者は、257〜1024バイトの長大パスワードを用いて
alpineユーザーとしてSSHログインに成功します。その後、doasを実行することで、一切のパスワード入力を介さずに root 権限（完全なシステム支配） を奪取します。
なお、OpenSSHのデフォルト設定（PermitRootLogin prohibit-password または no）により、/etc/shadow が root:* であっても root ユーザーへの直接SSHログインは防がれています。しかし、上記のように alpine ユーザー等を経由した doas / sudo による昇格パスが存在する場合、実質的に root 奪取と同等の被害をもたらします。
4. PoC検証とスキャナーが見落としがちな技術的罠
理論上の挙動と、現場での検証・診断ツールによる実測値との間には、誤判定を招く重要なギャップが存在します。
「接続（1 Connection） vs 試行回数（Prompt）」の技術的メカニズム
Alpine公式のアドバイザリでは「1回の接続（1 Connection）で成功する」と表現されているのに対し、研究者の検証コードや StepSecurity による詳細なラボ検証では、「同一SSHセッション（接続）内で、1回目のダミー試行（失敗）を経た後、2回目のプロンプトで長大パスワード（257〜1024バイト）を送る必要がある」という挙動が確認されています。
[SSH接続の確立 (1 Connection)]
│
├── 1回目のプロンプト試行: ダミーパスワード送信 ──> サーバー側拒否（Failed password）
│
└── 2回目のプロンプト試行: 257バイト以上の長大パスワード送信 ──> 成功！（Accepted password）
この現象は、初回接続時のクライアント・サーバー間のバッファ処理やSSHハンドシェイク、認証ステートの初期化タイミングに依存して発生します。1接続内の1発目のプロンプトで長大パスワードを送信した場合、初期バッファの制限等によりサーバー側で拒否されるケースがあります。2回目以降のプロンプト試行において、初めて crypt() のエラー結果と /etc/shadow の比較ロジックが合致し、バイパスが成立します。
脆弱性スキャナーの「偽陰性（False Negative）」リスク
この仕様は、自動脆弱性スキャナーによる判定において極めて深刻な盲点となります。
市場に存在する単純な自動スキャナーの多くは、SSHポートに接続し、1回だけ長大パスワードを送信してその応答（成功/失敗）を確認する簡易テストを行います。この場合、サーバー側は正しく拒否するため、スキャナーは「非該当 / 安全（Pass）」と誤った判定を出力してしまいます。
【警告：自動スキャナーの罠】 単純な1回試行型スキャナーによる「Pass（安全）」という判定結果を絶対に鵜呑みにしないでください！ スキャナーが「安全」と出力した場合であっても、対象環境が前述の「5つの前提条件」を満たしている限り、実際の攻撃ツール（2回試行型パケット）によって容易に侵入されます。判定はツールに頼らず、必ずパッケージの正確なリビジョン番号および設定ファイルで実施してください。
5. 実環境での悪用動向（In-the-Wild）
公表直後からのインテリジェンスデータは、攻撃者がいかに迅速に動いているかを証明しています。
公表から9時間以内の実攻観測
2026年11月5日の脆弱性公表からわずか9時間以内に、セキュリティ機関（Previdian や Aviatrix 等）が設置した Alpine Linux / OpenSSH ハニーポット環境において、本脆弱性を突いた実際の悪用試行および root 権限の奪取が確認されました。この攻撃スピードもフロンティアAIによるものだと考えられています。
観測された脅威インテリジェンスの概要は以下の通りです。
- 攻撃元IPアドレス:
89.116.89[.]18（日本にジオロケーション登録されたIPアドレス） - 観測された攻撃行動: 攻撃者は長大パスワードを用いて認証をバイパスした後、非対話型（non-interactive）SSHセッションを開設。即座に以下のシステム偵察コマンドを連続実行しました。
id
uname -a
hostname
クラウド / Kubernetes環境における水平展開リスク（East-West Attack）
Alpine Linux は軽量であるため、Kubernetes クラスタ内のマイクロサービス、CI/CD ランナー、エッジノードのベースイメージとして広く導入されています。
クラスタ内で外部露出している1つの Alpine コンテナが突破された場合、攻撃者はそのコンテナを拠点化します。コンテナ内に存在する Kubernetes ServiceAccount トークンや環境変数内のAPIキー、クラウド IAM 認証情報を奪取し、クラスタ内部でのラテラルムーブメント（水平展開） を通じてプロダクション環境全体へと被害を拡大させるリスクが現実化しています。
6. 検出と対策（今日すぐやるべきこと）
インフラエンジニアおよびSREが現場で直ちに実行すべき具体的・実践的なアクションプランを解説します。
6.1. 即時緩和策（ワークアラウンド）
パッケージ更新やシステムの再起動が直ちに実施できない緊急環境では、以下のいずれかの緩和策を講じてください。
緩和策1：パスワード認証の完全無効化（推奨）
/etc/ssh/sshd_config（または /etc/ssh/sshd_config.d/00-no-passwords.conf 等のドロップインファイル）を編集し、パスワード認証および対話型認証を無効化します。
# パスワード認証および対話型認証の無効化（鍵認証のみを許可）
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
設定反映手順（Alpine Linuxの場合）:
# 設定ファイルの文法チェック
sshd -t
# sshd サービスの再起動
rc-service sshd restart
※注: 設定変更前に、別セッションにてSSH鍵認証で正常にログインできることを必ず確認してください。
緩和策2：PAMモジュール経由への切り替え（第3の緩和策）
パッケージの全更新やパスワード認証の無効化が運用上困難な場合、openssh-server-pam パッケージを導入して UsePAM yes を有効化することで、認証処理がPAM経由となり、OpenSSH本体が未修正であってもバイパスが完全遮断されます。
# PAM対応パッケージの導入と設定変更
apk add openssh-server-pam
echo 'UsePAM yes' >> /etc/ssh/sshd_config
rc-service sshd restart
6.2. パッケージ更新と修正リビジョン
Alpine Linux の開発チームは、サポート中および一部EOL（サポート終了）のブランチに対し、修正パッチ（OpenSSH 10.6p2 相当のバックポート）を緊急リリースしました。
Alpine Linux ブランチ別・修正済みパッケージリビジョン一覧
| ブランチ (Branch) | 修正済み openssh-server パッケージバージョン | 備考 |
| edge | 10.6_p2-r0 |
最新開発ブランチ |
| v3.24 | 10.3_p1-r2 |
ポイントリリース 3.24.4 |
| v3.23 | 10.2_p1-r1 |
ポイントリリース 3.23.8 |
| v3.22 | 10.0_p1-r11 |
ポイントリリース 3.22.8 |
| v3.21 | 9.9_p2-r1 |
ポイントリリース 3.21.10 |
| v3.20 〜 v3.16 | 9.7_p1-r6 (v3.20), 9.6_p1-r3 (v3.19), 9.3_p2-r4 (v3.18), 9.1_p1-r7 (v3.17), 9.0_p1-r6 (v3.16) |
EOLブランチへの特別バックポート |
更新コマンド
# リポジトリの更新とパッケージのアップグレード
apk upgrade -U -a
6.3. 運用上の最大の落とし穴（コールアウト表示）
対策を実施する際、エンジニアが最も陥りやすい2つの罠に注意してください。
【注意：SSHバージョンバナー表記の罠（偽陽性／誤判定リスク）】 Alpine Linux をはじめとするディストリビューションでは、セキュリティ修正をバックポートして適用するため、sshd -V や外部バナースキャンで表示されるバージョン文字列（例: OpenSSH_10.3p1）はパッケージ更新後も変化しません。 バナースキャナーが「未対策」と警告を出す場合がありますが、実際は修正済みであるケースが存在します。正確な適用状況は、必ずパッケージマネージャーのビルドリビジョン番号（-r2 等）で確認してください。
# パッケージの正確なリビジョン確認コマンド
apk info -v openssh-server
【厳禁：パッケージ更新のみの放置と再起動忘れ】 apk upgrade を実行しただけでは、メモリ上で動いている既存の sshd デーモンは古いコードのまま稼働し続けます。必ず rc-service sshd restart 等でプロセスを再起動してください。
メモリ上の旧プロセス（deleted状態）検出ワンライナー
パッケージ更新後に旧デーモンがメモリ上に残り続けていないか、以下のコマンドで監査できます。
# 実行中の sshd プロセスが削除済みの旧バイナリを参照しているか確認
ls -l /proc/$(pgrep -f sshd)/exe | grep '(deleted)'
※上記コマンドで (deleted) と表示された場合、旧バイナリがメモリ上で動き続けているため、直ちに rc-service sshd restart を実行してください。
6.4. 侵入の痕跡（IoC）監査とログ判定手順
自社環境がすでに侵入されていないかを監査する手順です。
1. ログ監査コマンド
Alpine Linux の認証ログ（/var/log/messages または logread）から、パスワード認証の成功記録を検索します。
# syslog ファイルからの検索
grep "Accepted password for" /var/log/messages
# メモリバッファ（logread）を使用している場合
logread | grep "Accepted password for"
2. パスワード未設定アカウント（*）との突き合わせワンライナー
/etc/shadow 上でパスワード欄が「*」になっているアカウントを抽出し、それらのユーザーでのログイン成功記録がないか照合します。
# shadow 内でパスワード欄が '*' のアカウント一覧を取得
awk -F: '$2=="*"{print $1}' /etc/shadow
【判定基準と即時対応方針】 本来パスワードログインが不可能なはずのアカウント（alpine, root, 鍵専用ユーザー等）に対して Accepted password for のログが記録されていた場合、本脆弱性を突かれた侵入が発生したと判定してください。
即座に対象マシンをネットワークから隔離し、認証情報の無効化・フォレンジック調査・コンテナの破棄と再デプロイを実行してください。
7. まとめ
OpenSSH「sshole（CVE-2026-123158）」のインシデントは、単一のプロダクトのバグではなく、システム全体のアーキテクチャの組み合わせが生み出したセキュリティの教訓です。
本インシデントから私たちが得るべき教訓を整理します。
7.1. ミニマルディストリビューション採用におけるCライブラリ差分（glibc vs musl libc）の意識
Alpine Linux などのミニマルディストリビューションは、「イメージサイズの削減」「アタックサーフェスの縮小」という観点で極めて強力な選択肢です。しかし、基盤となる C ライブラリ（musl）のエラー処理仕様（256バイト超での * 返却）が、上位アプリケーション（OpenSSH）の前提ロジックと衝突したように、「軽量化のための仕様差分」が未知の攻撃表面を生むトレードオフを常に認識しなければなりません。
7.2. 「パスワード無効化アカウント（*）」に対する絶対的過信の脱却
「パスワードを設定していないから安全」「鍵認証専用にしているから安心」という前提は、下層ライブラリのバグや仕様変更によって崩壊し得ることが証明されました。 単にパスワードを設定しないだけでなく、PasswordAuthentication no を明示的に設定してパスワード認証機能そのものを切ること、不要なSSHデーモンをコンテナ内に導入しないこと（docker exec や kubectl exec への移行）、そしてネットワークレベルでの境界防御を徹底することが、弾力性（Resilience）のあるシステム構築に不可欠です。
7.3. 【最重要】フロンティアAI時代の侵害を前提とした際の我々が取るべき対策について
今回OpenSSHの10年間見落とされたバグを発見したのは、フロンティアAIです。また脆弱性公開後、わずか9時間以内にサイバー攻撃を開始できたのもフロンティアAIが活用されたのは間違いありません。サイバー攻撃の手口はますます高度化・高速化しており、インフラを支えるエンジニアの皆様が背負う責任と課題は日々大きくなっています。
SCSKでは、境界型防御（Perimeter Defense）が終焉を迎えた今、内部への侵入を100%遮断することは不可能な「Assume Breach（侵害前提）」の環境においては「侵害の阻止（Prevent Breach）」と同等に「被害半径の縮小（Reduce Blast Radius）」への投資をしなければなりません。
フロンティアAI時代に対応する「3層防御モデル」などの「多層防御（Depth in Defense）」と「ゼロトラストアーキテクチャ（Zero Trust Architecture）」が重要になっています。
特に、ランサムウェア被害で最も課題となっているラテラルムーブメント（横移動）を阻止する具体的なソリューションとして 次世代マイクロセグメンテーション Zero Networks をお勧めしております。Zero Networks は、サーバ・クライアントといったホスト単位でのネットワーク分離（セグメンテーション）するのはもちろん、特許技術を用いて管理ポート（RDP/SSH等）をデフォルトでは閉鎖し、ジャストインタイム（Just-In-Time：JIT）の多要素認証（MFA）を適用することが可能です（≒特権ID管理）これまでのレガシーなマイクロセグメンテーション製品とは異なり”完全エージェントレス型”で、通信可視化からAIによるポリシー自動生成が可能なため短期間の導入が可能です。
今回のOpenSSHの脆弱性においても、Zero Networks を実装していれば、SSHポートはデフォルトで閉鎖されているため、攻撃者がポートスキャンでサーバを探すことができません。また仮にサーバへSSHでアクセスしても、JITでMFA認証を施すことができるため、ログインを防ぐことが可能です。
すでに多くの引き合いをいただいておりますが、Zero Networks に興味をもたれた方は、ぜひ当社までお問い合わせください。
最後に、2026年11月11日 Zero Networks と、マイクロセグメンテーションと組み合わせることで完全なゼロトラストを実現する SASE（Secure Access Service Edge、サッシー）、これまでのウィルス対策ソフト・EDRと異なり、AI ディープラーニング（深層学習）にて非常に高い検知率を誇る次世代エンドポイントソリューション、そして攻撃者が侵入後に真っ先に狙うバックアップデータを保護し、確実な復旧を早期に実現するためのゼロトラストデータ保護ソリューションなど、多層防御とゼロトラストを実現する4つのベスト・オブ・ブリードのセキュリティソリューションをご紹介するオンラインセミナー（無料）を開催しますので、ぜひご参加ください。
最後までお読みいただき、ありがとうございました。