こんにちは。ＳＣＳＫの池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念　これまでと何が変ったか！？ 今回は、LifeKeeperの姉妹製品であるSingle Server Protection v10のライセンスについて解説したいと思います。   Single Server Protectionの名前が変わりました まずライセンス体系に入る前に、お伝えしないといけないこととして、Single Server Protectionのライセンス名称がv10に統一されています。   以前のライセンス名 v10のライセンス名 Windows版 Single Server Protection for Windows LifeKeeper v10 for SingleServer Linux版 Single Server Protection for Linux   Windows版のライセンス体系 続いて、Windows版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 上の図のように、旧バージョンではSingle Server Protection for WindowsにDB製品やIISが同梱されていましたが、新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっています。その分、LifeKeeper v10 for SingleServerの価格がお安くなっています。「LifeKeeper v10 for SingleServer」は、よりお求めやすい価格で可用性を実現して欲しいというサイオステクノロジー社の想いが垣間見れますね。 また旧バージョンではJP1/AJS Manager、Agent、HULFTとミドルウェアごとにARKが用意されていましたが、v10では「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きな変更点になります。 LifeKeeper v10 for SingleServerの価格が安くなるのはうれしいなぁ   Linux版のライセンス体系 続いて、Linux版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 Linux版の場合、旧バージョンでは多くのRecovery Kitが同梱されていましたが、Windows同様に新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっていまして、LifeKeeper v10 for SingleServerの価格がお安くなっています。 また本体に同梱されていたWebSphere MQや、JP1/AJSやHULFT用のRecovey Kitが「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きく変わった点となります。 まとめ LifeKeeperと同様にSingle Server Protectionについても、v10でライセンスが統一されましたが、OSごとに冗長化することができるミドルウェア製品が異なることから、それぞれの利便性を確保しつつ、ライセンス体系の見直しが行われてたようです。 「以前のバージョンでは同梱されていたRecovery Kitが、新バージョンで含まれていない」という事態にならないように、十分注意を払いながら必要なライセンスを購入していただければと思います。 少しでも不安な場合は、サイオステクノロジー社から認定されたSI&サポートパートナーであるSCSKにお問い合わせください。 オステクノロジー認定のSI&Supportパートナー （サイオステクノロジー公式サイト） Lifekeeperの製品体系 （サイオステクノロジー公式サイト） 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

2026年3月、 RFC 9849: TLS Encrypted Client Hello というインターネット標準のプロトコル仕様が発行されました。(正確には “Proposed Standard” ではありますが、標準と呼んで差し支えないでしょう。) この Encrypted Client Hello (以降 ECH と表記します) は、プライバシー保護という観点では望ましい技術ですが、Cato クラウドのようにセキュリティ機能を提供するサービスとは相性が悪い面があります。具体的には、ECH によって Cato が通信先のドメイン名を正しく認識できなくなり、セキュリティポリシーが適切に機能しなくなる可能性があります。 本記事では、ECH が Cato クラウドの動作にどのような影響を与えるのか、そしてどう対応すべきなのかを解説します。 TLS Encrypted Client Hello とは ECH については2年前のブログでも少し触れていましたが、その当時の懸念は少々杞憂でした。 Cato クラウドの FQDN ベースの制御の仕組みと課題 Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。 そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。 blog.usize-tech.com 2024.03.29 ECH とは何かざっくりと言いますと、TLS 通信においてクライアントが接続するサーバのドメイン名を保護するプロトコルです。ドメイン名そのものを機密にするものではなく、クライアントがどのドメイン名と通信するかを機密にするものです。 これまで、通信先のドメイン名を保護する技術として DNS 通信を暗号化する技術 (DNS over TLS / HTTPS / QUIC) や DNS の QNAME minimisation がありました。 それらによって名前解決の段階では通信先のドメイン名を保護できるものの、その後の TLS 通信を開始する際にクライアントが最初に送信する Client Hello メッセージにはサーバのドメイン名が暗号化されずに格納されています。そのため、通信経路上の監視者はクライアントの通信先のドメイン名を覗き見ることができてしまいます。 この課題を解決するために、通信先のドメイン名を暗号化して Client Hello に格納できるようにする標準技術として ECH が生まれました。 ECH の通信の流れ 基本的な通信の流れ ECH の基本的な通信の流れは次のようになります。 まず、クライアントは DNS の HTTPS レコードの名前解決を行い、ECH を作成するための暗号鍵とダミーのドメイン名を取得します。HTTPS レコードというものに馴染みのない方も居るかもしれませんが、2023年11月に標準化された DNS の新しいレコードタイプです。 次に、クライアントは TLS 接続を開始する際、本物のドメイン名を暗号化して Client Hello メッセージに埋め込み、外から見えるドメイン名の部分にはダミーのドメイン名を格納して送信します。これにより、本物のドメイン名を保護しつつ、通信経路上の監視者にはダミーのドメイン名と通信しているように見せることができます。 その後、サーバは Client Hello メッセージ内の暗号化されたデータを復号し、本物のドメイン名を取り出して適切に処理することで、最終的に TLS 接続が確立します。 TLS Inspection が有効な場合の通信の流れ Cato のように経路上で TLS Inspection を行う場合、通信の流れが少し変わってきます。 Cato が TLS Inspection を行う場合、Cato はサーバに成り代わって Client Hello メッセージを処理します。その際、Cato はメッセージ内の暗号化されたデータを復号できないため、本物のドメイン名を取り出すことができず、ECH にも対応していない Server Hello メッセージをクライアントに返すことになります。 クライアントは返ってきた Server Hello メッセージを見て、ECH が機能しないことを検知し、その TLS 接続をエラー終了させます。その後、ECH を使わない通常の TLS 接続にフォールバックし、本物のドメイン名を暗号化せずに Client Hello メッセージに格納して送信します。 それを受信した Cato は TLS を適切に処理できますので、クライアントと Cato との間で TLS 接続が正常に確立します。 ECH が Cato の通信に与える影響 ECH による TLS 接続が確立した場合、Cato はダミーのドメイン名しか認識できないため、本物のドメイン名に基づくセキュリティポリシーを適用できないことになります。さらに、本物のドメイン名を正しく認識できないことから、ドメイン名をもとに Cato が分類しているアプリケーションカテゴリやリスクスコアなどによる制御も適切に機能しなくなります。 そのため、Cato の基本的なセキュリティ機能である Internet Firewall や IPS に影響があり、本来ブロックすべき通信が通過してしまうという問題を引き起こします。 なお、ECH による TLS 接続が確立するということは TLS Inspection が有効ではない状態でもありますので、TLS Inspection が有効であることを前提としたセキュリティ機能 (IPSの一部、Anti-Malware、CASB、DLP など) には影響がありません。また、ECH による TLS 接続の前段階として本物のドメイン名の名前解決が行われますので、DNS Protection にも影響はありません。 ECH による通信の有無の確認方法 お客様の環境で ECH による通信が行われているかどうか、完全ではないものの確認方法はあります。 まずは、 ECH のテストサイト にアクセスしてみてください。 “You are using ECH.” と表示されれば ECH で通信が行われおり、”You are not using ECH.” と表示されれば ECH が使われていないことを示します。   また、テストサイト以外での ECH による通信を確認する方法として、Cato の CMA の Events 画面にて “Domain Name” がダミーのドメイン名であるイベントを確認する方法があります。 上記のテストサイトの場合ですと、ダミーのドメイン名は “public.tls-ech.dev” で、イベントには次のような記録が見つけられます。(TLS Inspection を有効にした環境での例で、本物のドメイン名のイベントも合わせて抽出しています。) 上の画像の中でも “Domain Name”, “Sub-Type”, “Action” の3つのフィールドに注目すると、ECH がどのように処理されているかが分かります。 表に書き起こすと次のようになっています。(古い時刻から順に並べ替えています。) 時刻 Domain Name Sub-Type Action 2026/03/27 09:44:18.078 public.tls-ech.dev Internet Firewall Monitor 2026/03/27 09:44:18.086 public.tls-ech.dev TLS Alert 2026/03/27 09:44:18.255 tls-ech.dev Internet Firewall Monitor まず最初に ECH を用いた TLS 接続が行われたため、Cato ではダミーのドメイン名でイベントが記録されており、Internet Firewall 機能は通過しています。 2つ目のイベントは TLS が Alert となっていますが、これは先ほどの説明の通り、Cato が ECH を処理できないためにクライアント (ブラウザ) が TLS 接続をエラー終了させていることを示しています。 3つ目のイベントは本物のドメイン名で記録されており、ECH を使わない通常の TLS 接続にフォールバックしたことを示しています。   2026年3月現在、ECH が有効な Web サイトは少なく、Cloudflare にホスティングされている Web サイトでしかまだ採用されていないように見受けられます。Cloudflare 上の Web サイトの場合、ダミーのドメイン名は全サイト共通で “cloudflare-ech.com” となっています。 “Domain Name” が “cloudflare-ech.com” であるイベントを確認し、Cato のいずれかのセキュリティ機能でブロックやエラー (Alert) となっていれば、ECH による通信は失敗していると判断できます。 ECH への対策方法 ECH によって Cato のセキュリティ機能が適切に働かない問題への対策方法はいくつか考えられ、現状で取りうる対策を以下に整理します。 1. TLS Inspection を有効にする 先ほどの説明や例の通り、TLS Inspection が有効であれば ECH による通信が失敗しますので、Cato のセキュリティ機能が適切に働きます。 TLS Inspection を有効にしていないお客様ですと、これを有効にすると既存の通信に多大な影響が及ぶため、この方法を採れないかもしれません。しかし、ダミーのドメイン名だけでも TLS Inspection を行うようにすれば ECH の問題を解消できますので、ご検討いただければと思います。 ただし、Cato では一部の OS (Android, Linux, その他不明なOS) の通信では TLS Inspection が行われないようになっていますので、それら OS が行う通信は ECH によってセキュリティ機能が働かないという問題があります。 2. ダミーのドメイン名の通信をブロックする ダミーのドメイン名の通信を Internet Firewall でブロックするというのも有効な対策です。ひとまず、”cloudflare-ech.com” 宛の通信をブロックすれば、現状では ECH に対策できていると言ってよいかと思います。 ただ、今後は Cloudflare 以外の Web サイトのホスティング事業者も ECH をサポートしてくることが予想されます。その場合、ダミーのドメイン名も事業者ごとに用意されるはずですので、ブロックすべきドメイン名を追加する運用も必要となってくる点に注意が必要です。 3. HTTPS レコードのクエリをブロックする もしもお客様が独自の DNS サーバをお使いであれば、その DNS サーバにて HTTPS レコードのクエリをブロックするという対策も考えられます。実際に試したわけではありませんが、Active Directory の DNS サーバをお使いであれば、HTTPS レコード (Type 65) をブロックする設定は可能だろうと思います。 ただ、OS やブラウザによっては意図しない DNS サーバを参照することもあるようですので、この方法も完全ではありません。 あとがき TLS Encrypted Client Hello (ECH) はインターネット標準のセキュリティ技術ではありますが、Cato のようなセキュリティサービスとは相性が悪い困った技術でもあります。 ECH によって引き起こされる問題への対策方法を3つ挙げましたが、1,2 の方法を両方とも採用することが現状での最適な対策と言えるかと思います。 しかし、現在行う対策が将来においても有効であるとは限らないため、Cato にて次のような機能が実装されることを期待しています。 クライアント OS を区別せず、ECH による TLS 接続を拒否する機能 (対策1の但し書きへの対応) ダミーのドメイン名であることを示す Application Category 定義の作成と随時更新 (対策2の但し書きへの対応) HTTPS レコードのクエリをブロックする機能（対策3の実現) ECH は Cato に限らず様々なセキュリティサービスでも同様の問題を引き起こすはずですので、不明点や疑問点などがありましたら何でもご相談いただければと存じます。 参考リンク RFC 9849: TLS Encrypted Client Hello Cato ナレッジベース: Website Hosted on Cloudflare Bypasses the Cato Firewall RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

Amazon LinuxでTransit Gateway Connectと接続してみた はじめに 皆さん、Transit Gateway Connectを試したことはありますか？ 仮想アプライアンスなどが必要と思って敷居を高く感じてませんか？ Amazon Linux 2023を利用してTransit Gateway Connect経由で経路広報などができます。 なんでAmazon Linuxで繋ぐの？ 事前の検証や軽い動作するためにお金がかかる仮想アプライアンスを使うのは躊躇いますよね ただでさえTGWやTGWアタッチメントにお金がかかるのに インスタンス代にプラスPay-As-You-Go…