KOBESOFT | 組み込み・IoT開発

セキュリティ

ゼロトラスト

すべてを信頼せず常に検証する考え方。

概要

ゼロトラスト（Zero Trust）は「何も信頼しない、常に検証する（Never Trust, Always Verify）」を原則とするセキュリティアーキテクチャの考え方です。従来の「境界型セキュリティ（内部ネットワークは安全）」モデルを根本から見直したものです。

従来の境界型セキュリティ（Perimeter Security）：

外部（信頼しない）  ║  内部ネットワーク（信頼する）
                    ║
  攻撃者            ║  デバイスA
  ─────→ ファイアウォール ─── デバイスB
                    ║  デバイスC
                    ║
一度内部に入ると「信頼済み」として自由に通信できる

ゼロトラストモデル：

すべての通信を検証

デバイスA ←─── 認証・認可 ───→ デバイスB
           ↕ 常に確認         ↕ 常に確認
      IDプロバイダー      アクセスポリシー
           ↕                   ↕
     内部ネットワークも         外部ネットワークも
     同様に扱う                同様に扱う

IoT・組み込みシステムへのゼロトラスト適用：

ゼロトラスト原則IoT実装
デバイスの明示的な検証X.509証明書によるmTLS認証
最小権限アクセスMQTTトピックポリシーで許可操作を限定
侵害を想定した設計セグメント分割、異常検知、自動遮断
継続的な監視デバイスの行動パターン監視
マイクロセグメンテーションデバイスグループごとのネットワーク分離

歴史・背景

  • 2010年 — John Kindervag（Forrester Research）が「No More Chewy Centers」でゼロトラストモデルを提唱。「内部ネットワーク＝信頼できる」という前提を否定
  • 2013年 — Google が内部向けにBeyondCorpプロジェクトを開始（社内ネットワークをゼロトラスト化）
  • 2014年 — BeyondCorpの概念が論文として公開
  • 2018年 — Google がBeyondCorpの詳細実装を公開。業界に大きな影響
  • 2019年 — Gartnerがゼロトラストをセキュリティの主流トレンドとして位置づけ
  • 2020年 — NIST SP 800-207「Zero Trust Architecture」公開。政府標準として確立
  • 2021年 — バイデン大統領令（EO 14028）でゼロトラスト採用を連邦政府機関に義務化
  • 2022年 — CISAがゼロトラスト成熟度モデルを公開
  • 2022年 — 産業用IoT分野でもゼロトラストの重要性が広く認識される
  • 2023年 — EU NIS2指令でゼロトラスト原則に基づくセキュリティ対策が促進

技術仕様

NIST SP 800-207 の7原則

NISTのゼロトラストアーキテクチャ（ZTA）は7つの原則で定義されます：

  1. データとサービスをリソースとして扱う — デバイス、サービス、データすべてをリソースとして保護対象に
  2. すべての通信を保護する — 内部/外部を問わずすべての通信を暗号化
  3. 個別のセッションごとにアクセスを許可 — 一度認証しても次のアクセスで再検証
  4. 動的ポリシーによるアクセス制御 — デバイス状態・ユーザー行動・リスクスコアに基づく
  5. すべてのデバイスの完全性を監視 — デバイスの健全性を継続的に検証
  6. 認証・認可を動的に実施 — リアルタイムで権限を評価・更新
  7. データを収集してセキュリティ状態を改善 — ログ・テレメトリによる継続的改善

IoTデバイスのゼロトラスト実装要素

デバイスアイデンティティ層:
  - デバイス証明書（X.509 / [PKI](/embedded/glossary/certificate-pki/)）
  - PUF値またはTPM/SE の固有識別子
  - デバイスフィンガープリント

デバイス健全性検証層:
  - セキュアブート成功確認
  - TPM PCR値によるインテグリティ計測
  - ファームウェアバージョン検証
  - 既知脆弱性のCVEチェック

アクセス制御層:
  - マイクロセグメンテーション（VLAN/SDN）
  - MQTTトピックレベルの権限制御
  - APIゲートウェイでの認可

継続的監視層:
  - 行動異常検知（通常と違うトピックへのPublish）
  - ネットワーク流量異常（DDoS等）
  - ファームウェア改ざん検知

デバイスゼロトラスト実装例（AWS IoT Core）

/* AWS IoT ポリシー例（ゼロトラスト原則に基づく最小権限） */
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:*:*:client/${iot:Connection.Thing.ThingName}",
      "Condition": {
        "Bool": {
          "iot:Connection.Thing.IsAttached": "true"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": [
        "arn:aws:iot:*:*:topic/devices/${iot:Connection.Thing.ThingName}/telemetry",
        "arn:aws:iot:*:*:topic/devices/${iot:Connection.Thing.ThingName}/status"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": [
        "arn:aws:iot:*:*:topicfilter/devices/${iot:Connection.Thing.ThingName}/commands"
      ]
    },
    {
      "Effect": "Deny",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:*:*:topic/devices/+/commands"
    }
  ]
}

デバイスは自分のトピックにのみPublish可能で、他デバイスへのCommandsトピックへのPublishは明示的にDenyされています。

動作原理

IoTゲートウェイへのゼロトラスト適用

IoTデバイス（フィールド）    ゼロトラストゲートウェイ   クラウド
      │                              │                     │
      │ 1. TLS ClientHello           │                     │
      │────────────────────────────→│                     │
      │ 2. デバイス証明書            │                     │
      │────────────────────────────→│                     │
      │                              │ 3. 証明書検証       │
      │                              │ 4. デバイスDB照合   │
      │                              │ 5. 健全性スコア計算 │
      │                              │    (FWバージョン、  │
      │                              │     最終接続日時等) │
      │                              │ 6. リスクスコア算出 │
      │ 7. 接続許可（or 拒否）       │                     │
      │←────────────────────────────│                     │
      │                              │                     │
      │ 8. データPublish             │                     │
      │────────────────────────────→│                     │
      │                              │ 9. ポリシーチェック │
      │                              │ 10. 承認 → 転送    │
      │                              │────────────────────→│
      │                              │ 11. 行動監視（継続） │

リスクベースの動的アクセス制御

# ゼロトラストポリシーエンジンの例

from dataclasses import dataclass
from enum import Enum
from datetime import datetime, timedelta

class RiskLevel(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

@dataclass
class DeviceContext:
    device_id: str
    firmware_version: str
    last_security_update: datetime
    cert_valid: bool
    cert_days_remaining: int
    known_vulnerabilities: list  # CVE IDs
    anomaly_score: float  # 0.0 ~ 1.0
    location: str

def calculate_risk_score(ctx: DeviceContext) -> float:
    """デバイスのリスクスコアを計算（0.0=低リスク, 1.0=最高リスク）"""
    score = 0.0
    
    # 証明書の問題
    if not ctx.cert_valid:
        score += 0.4  # 証明書無効は重大
    elif ctx.cert_days_remaining < 7:
        score += 0.2  # 証明書期限切れ間近
    
    # セキュリティ更新の遅れ
    days_since_update = (datetime.now() - ctx.last_security_update).days
    if days_since_update > 30:
        score += min(0.3, days_since_update / 100)
    
    # 既知脆弱性
    critical_cves = [cve for cve in ctx.known_vulnerabilities
                     if get_cvss_score(cve) >= 9.0]
    score += len(critical_cves) * 0.15
    
    # 行動異常
    score += ctx.anomaly_score * 0.3
    
    return min(1.0, score)

def get_access_policy(ctx: DeviceContext) -> dict:
    """リスクスコアに基づくアクセスポリシーを返す"""
    risk_score = calculate_risk_score(ctx)
    
    if risk_score < 0.3:
        return {
            "allowed_topics": ["telemetry", "status", "commands"],
            "max_message_rate": 100,  # msg/min
            "data_retention": 30,     # days
        }
    elif risk_score < 0.6:
        return {
            "allowed_topics": ["telemetry"],  # コマンド受信を制限
            "max_message_rate": 10,
            "alert": "Security update required",
        }
    elif risk_score < 0.9:
        return {
            "allowed_topics": [],  # 通信を停止
            "quarantined": True,
            "action": "force_security_update",
        }
    else:
        return {
            "blocked": True,  # 接続遮断
            "alert": "CRITICAL: Device compromised suspected",
            "action": "security_team_notification",
        }

マイクロセグメンテーションの実装

# OpenWRT / iptables によるIoTデバイスのマイクロセグメンテーション

# デバイスグループ別のVLAN割り当て
# VLAN 100: 信頼度高（最新FW、証明書有効）
# VLAN 200: 通常IoT
# VLAN 300: 隔離（古いFW、未更新）

# VLAN 300（隔離ゾーン）の通信制限
iptables -I FORWARD -i vlan300 -o vlan100 -j DROP  # 隔離→高信頼ゾーン禁止
iptables -I FORWARD -i vlan300 -o vlan200 -j DROP  # 隔離→通常ゾーン禁止
# IoTゲートウェイへのみ接続許可（OTA更新のため）
iptables -I FORWARD -i vlan300 -d 10.0.100.50 -p tcp --dport 8883 -j ACCEPT
# それ以外は全DROP
iptables -I FORWARD -i vlan300 -j DROP

用途・ユースケース

スマートファクトリー（インダストリー4.0）

工場内のPLC、センサー、ロボットなどOT（Operational Technology）機器をゼロトラストで管理する場合：

工場向けゼロトラスト実装:

  生産ライン機器           OTセキュリティゲートウェイ
  （PLC、センサー）              │
        │                        │ ・OPC-UA証明書認証
        └──── TLS接続 ──────────→│ ・ホワイトリスト通信制御
                                 │ ・異常プロセス値の検知
                                 │
                            IT ネットワーク
                         （MES/ERPシステム）
                                 │
                            ICS-SOC（監視センター）

ゼロトラストの段階的導入ロードマップ

フェーズ1（基礎）: 6ヶ月
  ✓ デバイスアイデンティティの確立（X.509証明書）
  ✓ すべての通信のTLS化（mTLS含む）
  ✓ デバイス台帳（インベントリ）の作成

フェーズ2（可視化）: 6ヶ月
  ✓ ネットワークフローの完全な可視化
  ✓ デバイス行動のベースライン確立
  ✓ SBOMによる脆弱性追跡の自動化

フェーズ3（制御）: 1年
  ✓ マイクロセグメンテーションの実装
  ✓ 動的ポリシーエンジンの導入
  ✓ 自動隔離・修復フローの整備

フェーズ4（最適化）: 継続
  ✓ AI/MLを使った異常検知の高度化
  ✓ 継続的なポリシーの自動調整
  ✓ 定期的な侵入テスト・レッドチーム演習

実装・開発のポイント

デバイス上でのゼロトラスト実装

デバイス側でも「自分が接続するサーバーを常に検証する」ゼロトラスト原則を実装します：

/* ゼロトラスト原則に基づくデバイス側実装 */

/* 1. サーバー証明書を必ず検証（VERIFY_REQUIRED） */
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED);

/* 2. 証明書ピンニング（特定サーバーのみ信頼） */
static const uint8_t PINNED_SERVER_CERT_HASH[32] = { /* ... */ };

int server_cert_verify_callback(void *data,
                                  mbedtls_x509_crt *cert,
                                  int depth, uint32_t *flags) {
    if (depth == 0) {
        uint8_t cert_hash[32];
        mbedtls_sha256(cert->raw.p, cert->raw.len, cert_hash, 0);
        
        if (memcmp(cert_hash, PINNED_SERVER_CERT_HASH, 32) != 0) {
            *flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED;
            LOG_ERR("Server certificate pin mismatch!");
            return -1;
        }
    }
    return 0;
}

mbedtls_ssl_conf_verify(&conf, server_cert_verify_callback, NULL);

/* 3. 接続先ホスト名の検証（SNI） */
mbedtls_ssl_set_hostname(&ssl, "iot.example.com");

/* 4. 定期的な再認証（長時間接続でも証明書が有効か再確認） */
void periodic_reauth_task(void *pvParam) {
    while (1) {
        vTaskDelay(pdMS_TO_TICKS(3600 * 1000)); /* 1時間ごと */
        
        /* セッションを意図的に切断・再接続して再認証 */
        mbedtls_ssl_close_notify(&ssl);
        reconnect_with_fresh_handshake();
    }
}

テレメトリによる継続的な健全性報告

/* デバイス健全性テレメトリの送信 */
#include "cJSON.h"

void send_device_health_telemetry(void) {
    cJSON *health = cJSON_CreateObject();
    
    /* デバイス状態情報 */
    cJSON_AddStringToObject(health, "deviceId", get_device_id());
    cJSON_AddStringToObject(health, "fwVersion", FIRMWARE_VERSION);
    cJSON_AddNumberToObject(health, "certDaysRemaining",
                             get_cert_days_remaining());
    
    /* セキュアブート状態 */
    cJSON_AddBoolToObject(health, "secureBoot",
                           is_secure_boot_enabled());
    
    /* 最終OTA更新 */
    cJSON_AddNumberToObject(health, "lastOtaTimestamp",
                             get_last_ota_timestamp());
    
    /* メモリ・スタック健全性 */
    cJSON_AddNumberToObject(health, "freeHeap", esp_get_free_heap_size());
    cJSON_AddNumberToObject(health, "minFreeHeap",
                             esp_get_minimum_free_heap_size());
    
    /* 異常カウンタ */
    cJSON_AddNumberToObject(health, "authFailCount",
                             get_auth_failure_count());
    cJSON_AddNumberToObject(health, "watchdogResets",
                             get_watchdog_reset_count());
    
    char *json_str = cJSON_PrintUnformatted(health);
    mqtt_publish("devices/" DEVICE_ID "/health", json_str);
    
    cJSON_Delete(health);
    free(json_str);
}

他技術との比較

ゼロトラスト vs 境界型セキュリティ

比較項目境界型セキュリティゼロトラスト
基本前提内部は安全すべてを疑う
認証タイミング境界通過時のみすべてのアクセスで
横移動（ラテラルムーブメント）対策弱い強い（マイクロセグメント）
VPN依存高い低い（なくせる）
IoTデバイス管理困難適している
実装コスト低い（最初）高い（最初）
侵害時の被害範囲広い（内部に入れば自由）狭い（セグメント内に限定）

ゼロトラスト成熟度レベル（CISA モデル）

レベル状態IoT観点
Traditionalペリメータ依存、静的ポリシーデフォルトパスワード、TLSなし
Initial部分的なアイデンティティX.509導入、基本mTLS
Advanced動的ポリシー、MFAリスクベースアクセス、OTA更新
Optimal完全自動化、AIドリブン自動隔離、リアルタイム異常検知

多くのIoTシステムは現在 Traditional〜Initial の段階にあり、Advanced への移行が急務です。特に重要インフラ（電力、水道、医療）では、Advanced以上のゼロトラスト成熟度が求められるようになっています。

関連用語

TLS / DTLS 暗号化 セキュアブート OTAセキュリティ セキュリティアップデート MQTT AWS IoT Core Azure IoT Hub

参考リンク

RFC RFC 7519: JSON Web Token (JWT) NIST SP 800-207 Zero Trust Architecture CISA Zero Trust Maturity Model John Kindervag - Zero Trust 論文（原典）
用語辞典トップへ戻る