みなさん、こんにちは！今回は、ITとOT（制御システム）の最前線で注目されている「ゼロトラストアーキテクチャ」について、一緒に楽しく学んでいきましょう！
「ITのセキュリティはなんとなく分かるけれど、工場やプラントを動かすOT（Operational Technology）の世界はちょっと勝手が違うぞ…」「ゼロトラストって言葉を聞くけど、具体的にどうすればいいの？」そんな風に悩んでいる新人IT担当者の方や、セキュリティに初めて触れる開発者の方も多いはずです。
大丈夫です。難しい専門用語の裏側にある「攻撃者の手口」と「現場で使えるリアルな対策」を、身近な例えを交えながら一歩ずつ紐解いていきますね！
—
1. 家の鍵に例える「境界防御」の限界と、OT環境のリアル
まずは、私たちが普段暮らしている「お家」を想像してみてください。
昔ながらの防犯対策といえば、こんな感じですよね。
- 頑丈な玄関の鍵を閉める
- 高い塀をめぐらせる
- 「うちは安全だ！」と信じ込む
これがいわゆる従来の「境界防御（ペリメータ・セキュリティ）」という考え方です。ITやOTの世界でも長年、「社内ネットワーク（塀の内側）に入ってしまえば、あとは全員信用する」というスタイルが主流でした。
攻撃者は「合鍵」や「窓の隙間」を知っている
しかし、現代のサイバー攻撃者は非常に狡猾です。一度フィッシングメールやサプライチェーンの脆弱性をついて社内ネットワークに侵入してしまえば、あとは「塀の内側」なので、やりたい放題暴れまわることができます。
特に、工場やプラントで使われるOT環境（PLCやSCADAなどの制御デバイス）は、かつては「外部のインターネットとは繋がっていないから安全（エアギャップ）」と言われていました。しかし、業務効率化やIoT化の波によって、ITネットワークとOTネットワークがどんどん繋がってきています。
もし、IT側のパソコンが1台でも乗っ取られたらどうなるでしょうか？ 境界防御の前提が崩壊した今、攻撃者は何のチェックも受けずに、そのまま工場の心臓部であるSCADAサーバーやPLC（プログラマブル論理コントローラー）に到達できてしまいます。これは、「泥棒が一度玄関を突破したら、家中の部屋の鍵がすべて開けっ放しになっている状態」と同じなのです。恐ろしいですよね。
—
2. ゼロトラストってなに？「何も信用するな、すべて検証せよ」
そこで登場するのが、今回の主役である「ゼロトラスト（Zero Trust）」です。
ゼロトラストの基本理念はシンプルです。
「社内であろうが、一度認証した端末であろうが、一切信用しない。通信やアクセスが発生するたびに、本当に信頼できる相手か『身元確認』と『健康状態のチェック』を行う」
身近な例えで言うと、高級マンションや重要機密を扱う研究所を想像してください。
たとえ正面玄関をパスポートで通過した人であっても、エレベーターに乗る時、特定の部屋に入る時、さらには金庫を開ける時など、あらゆる場所で「社員証の提示」と「その都度の顔認証・権限チェック」が求められますよね。
これをOT環境に応用するのが、今回のテーマである「OT環境におけるゼロトラストアーキテクチャの適用」なのです。
—
3. 段階的に導入する！OTゼロトラストの具体的なアプローチ
「じゃあ明日から工場全体のネットワークを全部作り直そう！」……と言いたいところですが、24時間365日止まることが許されない制御システムの現場で、そんな大工事はいきなりできませんよね。
だからこそ、「段階的な導入（スモールスタート）」が極めて重要になります。現場の運用を止めずに、できるところから確実に固めていきましょう。
ステップ1：通信の「可視化」と「セグメンテーション（マイクロセグメンテーション）」
まずは、OTネットワークの中で「どのデバイスとどのデバイスが、どんな通信（ModbusやProfinetなどの産業用プロトコル）をしているのか」を完全に把握することから始めます。
泥棒が入ってきたときに被害を最小限に抑えるため、部屋の中にさらに小さな仕切りの壁（マイクロセグメンテーション）を作ります。
ステップ2：デバイス単位・通信単位での検証（コンテキストベースのアクセス制御）
通信を行う際、単にIPアドレスを見るだけでなく、以下の要素を組み合わせて検証します。
- アクセスしようとしている端末は、セキュリティパッチが最新か？
- その操作は、現在の時間帯や作業者のシフトと一致しているか？
- やり取りされているModbusやOPC UAのコマンドに、異常な不正コードが含まれていないか？
—
4. 実践！プロキシやリバースプロキシで「通信を仲介・検証」する設定例
「すべてを検証する」といっても、具体的にどうコードや設定に落とし込むのか気になりますよね。
ここでは、IT/OTの境界や、OTネットワーク内の重要な中継地点に配置するリバースプロキシやAPIゲートウェイを想定し、「不正な通信や怪しいヘッダーを持つリクエストを遮断する設定」のサンプルを見てみましょう。
実際の現場では、NginxなどのWebサーバーやAPIゲートウェイをプロキシとして挟み、デバイスからの通信を一度受け止めて検証を行います。以下は、NGINXにおけるセキュリティヘッダーの付与や、不正なリクエストを弾く設定のイメージです。
# /etc/nginx/conf.d/ot_zero_trust_proxy.conf
# OT環境の手前に置くリバースプロキシのセキュリティ設定例
server {
listen 443 ssl;
server_name scada-internal-gateway.local;
# 堅牢なSSL/TLS証明書の設定（通信の暗号化はゼロトラストの基本です）
ssl_certificate /etc/nginx/ssl/ot_gateway.crt;
ssl_certificate_key /etc/nginx/ssl/ot_gateway.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location /api/v1/control/ {
# 1. デバイスの認証トークン（JWT等）がリクエストヘッダーに含まれているか検証
if ($http_authorization = "") {
return 401; # 認証情報がない場合は即座に拒否
}
# 2. 独自のカスタムヘッダーで「デバイスの健全性（セキュリティ状態）」を確認
# 例: 端末のEDR（Endpoint Detection and Response）が「healthy」を返しているか
if ($http_x_device_health != "healthy") {
return 403; # 端末がマルウェア感染疑いなどの場合はアクセス禁止
}
# 3. 信頼できる内部のSCADA/PLCサーバーへ転送
proxy_pass https://10.100.50.10:8443/;
# プロキシ経由でも元のクライアント情報をしっかりとバックエンドに引き渡す
proxy_set_index Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# 上記以外の未知のエンドポイントへのアクセスはすべてシャットアウト
location / {
return 403;
}
}この設定のポイント
$http_authorization: 通信を行うたびに身分証明書（トークン）の提示を義務付けています。$http_x_device_health: 単に「パスワードを知っているか」だけでなく、「その端末自体が安全な状態（健康な状態）か」というコンテキスト（文脈）をチェックしています。- 「一歩ずつ対策を学んでいきましょう！」と言ったように、まずは重要な制御コマンドの入り口（
/api/v1/control/）だけにこのプロキシを挟むところから始めるのが、現場を混乱させないコツです。
—
5. まとめと次のステップ
今回は、OT環境におけるゼロトラストアーキテクチャの重要性と、具体的な考え方を家の鍵やプロキシの設定例を交えて解説しました。
- 境界防御（昔のやり方）だけでは、一度侵入されたときに太刀打ちできない。
- ゼロトラストとは、「何も信用せず、通信やデバイスの状態をその都度検証する」こと。
- 工場の現場を止むを得ず動かすためにも、スモールスタートでセグメンテーションやプロキシによる検証を段階的に導入していく。
セキュリティは一朝一夕に完璧なものができるわけではありません。しかし、こうした小さな「疑う仕組み」を積み重ねていくことで、攻撃者にとって「攻略しにくい、旨味のないターゲット」に変えていくことができます。
日々の開発やインフラ構築の中で、「本当にこの通信は信用して大丈夫か？」という視点を少しずつ取り入れて、一緒にセキュアなシステムを育てていきましょう！それではまた次回の記事でお会いしましょう！
コメント