600以上の条件に基づくマイクロセグメンテーション
従来のZTNAソリューションの多くは、単純なロールベースのポリシーに依存していますが、Genians ZTNAはNAC(Network Access Control)の技術スタックを活用し、極めて粒度の高いノード分類を実現しています。境界型セキュリティの限界が露呈する中、VPNからZero Trust Network Accessへの移行において、この識別能力は極めて重要な要素となります。
分類マトリックスの構成要素
ノードグループの定義には、以下の4つのカテゴリにわたる600以上の条件が組み合わされます。これにより、静的な属性だけでなく、動的なコンテキストに基づいたアクセス制御が可能になります。
- ネットワーク識別子: IP/MACアドレス、オープンポート、トラフィックパターン
- システムメタデータ: プラットフォームタイプ、システム情報、ノードタイプ、登録日
- セキュリティポスチャ: アンチウイルス(AV)の状態、エージェントのヘルスチェック、パスワード設定、OSアップデート状況
- コンテキストデータ: ユーザーアカウント、カスタムタグ、アプリケーション固有のデータ
これらの条件を組み合わせることで、「最新のAVシグネチャを保持し、企業ドメインに参加しているWindows 11デバイスが、外部IPからアクセスしている場合のみ許可する」といった、多層的な条件分岐が論理的に構成されます。
二段階ポリシー構造:ComplianceとPermission
アクセス制御は、以下の二段階の検証プロセスを経て実行されます。このアーキテクチャは、ホワイトリストベースの「Deny by Default」原則に基づいて動作し、明示的に許可されていないトラフィックはすべて遮断されます。
- Compliance Policy(コンプライアンスポリシー): デバイスがアクセス権を検討される前に満たすべき最低限のセキュリティ基準(必須ソフトウェアのインストール、パッチ適用状況など)を定義します。
- Permission Policy(許可ポリシー): コンプライアンスが確認された後、特定のサービス、アプリケーション、アクセス場所、および時間枠に対する具体的な権限を付与します。
{
"policy_name": "Secure_Remote_Access_v1",
"compliance_criteria": {
"os_version": "Windows 11 22H2+",
"antivirus": "Active",
"patch_level": "Critical_Only",
"agent_status": "Healthy"
},
"permission_rules": [
{
"service": "Internal_ERP",
"access_method": "SDP_Gateway",
"authentication": "FIDO2_Passkey",
"action": "ALLOW"
}
],
"default_action": "DENY"
}
パスキー認証によるパスワードレス実装
フィッシング攻撃やパスワードの使い回しによるリスクを排除するため、Genians ZTNAはFIDO2/WebAuthn規格に準拠したパスキー認証を統合しています。これにより、認証プロセスの堅牢性が大幅に向上しています。
認証メカニズムとセキュリティ
パスキーは公開鍵暗号方式を採用しており、秘密鍵はユーザーのデバイス(スマートフォンやPC)内のセキュアエレメントに保管されます。サーバー側には公開鍵のみが保存されるため、サーバーからの認証情報漏洩リスクが構造的に排除されています。また、パスキーはドメインに紐付けられているため、フィッシングサイトでの誤用を防止する特性を持ちます。
運用シナリオ
- 管理者コンソール: 最も機密性の高い管理エンドポイントへのアクセスをパスキーで保護します。
- Captive Web Portal (CWP): 一般ユーザーが内部リソースにアクセスする際のゲートウェイとして機能します。
- マルチファクタ認証 (MFA): SMSやメール認証と組み合わせたMFAの要素、あるいはプライマリ認証として柔軟に構成可能です。
デスクトップに生体認証ハードウェアがない場合、Bluetoothを介してスマートフォン(Android/Chrome, iPhone/Safari)をローミング認証器として使用するクロスデバイス認証もサポートされており、利便性とセキュリティの両立が図られています。
SBOMによるソフトウェアサプライチェーンの透明性
Log4jの脆弱性事案以降、ソフトウェア構成要素の可視化は不可欠な要件となりました。Genians ZTNAは、製品の全コンポーネントに対してSBOM(Software Bill of Materials)を提供し、サプライチェーンの透明性を確保しています。
標準フォーマットと生成プロセス
SBOMは、業界標準であるCycloneDX(OWASP)およびSPDX(Linux Foundation, ISO/IEC 5962:2021)フォーマットで提供されます。ビルド時に Syft などのツールや言語固有のプラグインを使用して自動生成され、リリースパッケージごとに最新の構成リストが維持されます。
コンポーネント別の粒度
監査の精度を高めるため、SBOMはモノリシックな1つのファイルではなく、コンポーネントごとに分割して提供されます。これにより、特定のライブラリにCVEが報告された際、該当するバージョンがどのコンポーネントに含まれているかを即座に特定できます。
| コンポーネント | フォーマット | 生成ツール例 |
|---|---|---|
| Management Console (WebUI) | CycloneDX | cyclonedx-npm |
| Engine (centerd) | CycloneDX | cyclonedx-gomod |
| Agent (Windows/Linux/macOS) | CycloneDX | Syft |
Findings
Genians ZTNAは、単なるアクセス制御の置き換えではなく、NACの深い可視性とFIDO2、SBOMといったモダンなセキュリティ規格を統合することで、ゼロトラストの概念を実務的な運用レベルへと昇華させています。特に、600以上の条件を組み合わせた動的なマイクロセグメンテーションは、ランサムウェアによるラテラルムーブメントを抑制する上で極めて有効な防御層を形成します。導入にあたっては、ポリシーサーバーへのドメイン割り当てなど、パスキーのドメインバインディング特性を考慮したネットワーク設計が重要となります。