Japan QRadar User Group

はじめに

みなさま
こんにちは、テクニカルセールスの瀬尾です。

今回のブログではQRadar on CloudとDisconnected Log Collector（DLC）の接続時に設定する証明書について解説をしたいと思います。

DLCは、Data GatewayやEvent Collectorの軽量かつ安価な代替ソフトウェアでありイベントの収集および転送が可能です。対応しているイベントのプロトコルは多少限定的ですが、メジャーな製品はカバーしておりその範囲も拡大中です。Data GatewayのIPアドレス制限や、設置上限を気にせずにログの収集を行うことができるメリットもあります。

DLCからQRadar on Cloudへログを送信する際はTLS over TCPで暗号化された状態で行われます。TLS over TCPの通信を確立するためにDLCホストとQRadar on Cloudでそれぞれ証明書の設定を行う必要がありますが、その部分が少し複雑なため今回は設定に必要な証明書周りの説明著者の体験をもとに行います。




証明書について（※すでにご存知の方は具体的な導入手順の部分までスキップ可能です）

かなり初歩的な部分なのでもちろんご存知の方もいると思いますが、かくいう私がこの辺りからあまりわかっていなかったので備忘録的に記載しておきます。

証明書は一言で言うと、接続を行う際に確認をする身元を示すためのファイルです。証明書には大きく2つあり、サーバー側が信頼できるものであることを証明するサーバー証明書と、クライアント側が信頼できるものであることを証明するクライアント証明書に大別することができます。

QRoCにおけるTLS 接続では、クライアントとサーバーの両方が証明書で構成されます。クライアントがサーバーに接続すると、サーバーは最初に証明書を提示して身元を証明します。クライアントは、証明書が信頼できる機関によって発行されたものであることを確認し、証明書に期待されるホスト名が含まれていることを確認します。この部分は、Web サイトに接続するときにブラウザーが行うことと同じです。それが成功すると、クライアントは自身の証明書をサーバーに提示して身元を証明します。サーバーは、クライアント証明書が信頼できる機関によって発行されたことを確認し、既知の ID (この場合は UUID) が含まれていることを確認します。

証明書のファイル形式としてはエンコードの仕方や用途によって変わりますが、.derや.pem、.crt/.cerなどが使用されます。また、証明書を作成する際に.keyという拡張子の鍵ファイルも出力されます。余談ですが、証明書と鍵のペアのファイルは.pfx/.p12といった拡張子で使用されることがあります。

下記サイトで下表の様にまとめられており、こちらがわかりやすいかと思います。
（設定する上で複数の証明書の形式が出てくるため頭に入っているとわかりやすいです）

デジタル証明書のエンコードと拡張子の違い （https://www.nextdoorwith.info/wp/se/digital-certificate-encoding-extensions-difference/)




認証局について

証明書は認証局によって発行されますが、認証局は大きくパブリック認証局とプライベート認証局に分けることができます。パブリック認証局は外部からの審査によってセキュリティが担保された認証局のことを指します。パブリック認証局で証明書を発行する場合は基本的に料金を支払う必要があります。ただし、Let's Encryptなどの無料で利用できるパブリック認証局も存在しています。

一方でプライベート認証局は誰でもローカルのPCなどにたてて証明書を発行することができるようになっています。プライベート認証局を建てるための有名なツールでは「easy-rsa」などが挙げられます。後述しますが、今回紹介するQRadar on CloudとDLCの接続を行う方式ではパブリック認証局とプライベート認証局の両方の証明書を使用することになります。





QRadar on CloudとDLCで使用する証明書について

まずは今回ポイントとなるDLCとQRoCでの証明書に関する考え方を解説しておきます。
今回は海外のQRadar Communityで掲載されていた下記概念図の様に設定しますが、証明書はたすき掛けの様に信頼関係が成り立つことになります。

・DLC（左）はLet's Encryptを信頼するため、Let's Encryptで署名されたQRoCのサーバー証明書を信頼しています
・QRoC（右）はプライベート認証局を信頼するため、DLCのクライアント証明書を信頼するしています
　（→ プライベート認証局のRoot証明書をDevOpsに渡して信頼してもらいます）



上記の様に設定する1つ目の理由は、QRoCのEvent Collector（ログ収集口）に設定するTLS通信用の証明書がパブリック認証局によって署名されたものに限定しているためです。また、QRoCはセキュリティ・ポリシーによりユーザーは一定の管理者権限とCLIへのアクセスが制限されています。そのため、QRoC側の証明書の発行及び設定はDevOpsに依頼する必要があります。

DevOpsに依頼をすることでLet's Encryptで署名された証明書が発行されます。ただ、Lets's Encryptの証明書は3ヶ月更新が必要になりますが、DevOps側で自動更新が行われるためユーザーによる追加の設定や管理は不要です。

一方でDLC（クライアント）側の証明書についてはユーザーが任意に設定することが可能です。ただ、追加料金や運用の負荷をかけない一番簡単な方法としてプライベート認証局を立てて自己署名を行う方法があるため、マニュアルではそちらがガイドされています。（QRoC側で利用されているLet’s Encryoptでは３ヶ月更新が必要になってしまいます）

上記の理由より今回利用する認証局がサーバー側とDLC側でたすき掛けをする様な形をとっています。




具体的な設定手順について

上記の概念を理解していれば、基本的にはDLCの接続マニュアルに記載されている下記の手順から設定が可能です。
今回は個人的に苦戦した☆マークのついた手順を重点的に説明します。

1. DLCでの署名要求（CSR）作成 
2. Easy-RSAを使用したプライベート認証局の作成と署名 ☆
3. DLCでの証明書インポート
4. サポートへサーバー証明書の要求とプライベート認証局のRoot証明書を送付
5. QRoCコンソールでのログソース（DLC）の登録および作成


1. DLCでの署名要求作成
まずはDLCで署名要求を作成します。
下記のコマンドからトラストストアの更新およびクライアント証明書要求を行います。

/opt/ibm/si/services/dlc/current/script/generateCertificate.sh -csr (-2k | -4k)

都道府県や部署名など必要な情報を入力すると以下のディレクトリに.csrの署名要求ファイルが作成されます。
＜UUID＞部分はDLC固有に設定された値が入ります。

/opt/ibm/si/services/dlc/keystore/< UUID> /dlc-client.key

2.Easy-RSAを使用したプライベート認証局の作成と署名
次に、easy-rsaをたてて署名要求に対して署名を行います。まずはeasy-rsaを認証局を建てるホストにクローンします。
紹介したCommunity Blogでもある程度の操作を説明していますが、私は下記のサイトを参考に初期セットアップを行いました。
https://smile-jsp.hateblo.jp/entry/2021/02/09/150636

git clone git@github.com:OpenVPN/easy-rsa.git #クローンの作成

クローンを実行すると下記の様なフォルダとファイルが生成されますが、基本は easyrsa/easyrsa3 のフォルダ内で作業を実施することとなります。本体のシェルスクリプトもeasyrsa3のフォルダ内に存在しています。


この後、下記のコマンドからeasyrsaの初期化を行いルートキーの生成を行います。その際にパスワードの設定を要求されるため入力を行います。

./easyrsa init-pki && ./easyrsa build-ca #easy-rsaの初期化＆認証局の構築

完了すると下記のフォルダに認証局のルート証明書と認証局の秘密鍵が生成されます。
このルート証明書は後ほどDevOpsに送付します。

easyrsa/easyrsa3/kpi/ca.crt #ルート証明書
easyrsa/easyrsa3/kpi/private/ca.key #秘密鍵

ここまで確認ができれば次は1. DLCでの署名要求作成で作成したdlc-client.csrを easyrsa/easyrsa3/ にコピーして下記コマンドからインポート及び署名を行います。

./easyrsa import-req dlc-client.csr dlc-client #署名要求をインポート
./easyrsa sign-req client dlc-client #署名を実行

上記のコマンドが実行できていたらdlc-client.crtが生成されます。
生成されたファイルを下記コマンドからpem形式に変換してDLCホストの/tmp あるいは任意のフォルダへ返します。



openssl x509 -in source.crt -out tmp.der -outform DER #DER形式へ変換
openssl x509 -in tmp.der -inform DER -out dest.pem -outform pem #PEM形式へ変換

3.DLC証明書のインポート
あとはマニュアルに記載されている通り、DLCホスト上で下記のコマンドから証明書をインポートします。

/opt/ibm/si/services/dlc/current/script/generateCertificate.sh -p12 
/tmp/dlc-client.pem 

4.サポートへサーバー証明書の要求とプライベート認証局のRoot証明書を送付
ここまで来ればあとはマニュアルに沿って必要な情報をDevOpsに送付および依頼して作業を進めることで設定が完了します。

サポートへ送付する情報 / 要求
・TLS syslog 証明書の要求
・Easy-rsaのroot証明書を pem 形式で添付

サポートチケットでは下記の内容について返信がきます。

サポートからの返信内容
・鍵ストア・ファイル名    
・鍵ストア・ファイル・パスワード    
・トラストストア・ファイル・パス    
・トラストストアのパスワード


5. QRoCコンソールでのログソース（DLC）の登録および作成
最後は4.の手順で得られた情報をもとにQRadar on Cloudのコンソール側でログソースの登録と設定を行えば通信を始めることができるようになります。

Log Source Managerのアプリケーションから「Disconnected Log Collector」を選択し、下記のプロパティについて入力して登録を行います。


その後、Log Source Managerの「ログ・ソース」からDLCをログソースとして登録します。登録する際のログ・ソース・タイプとしては「Universal DSM」を、ログ・ソース・プロトコルとしては「IBM QRadar DLC Protocol」を選択します。

プロトコル構成画面については下記のパラメーターについてサポートから受け取った情報を確認しながら入力します。Authentication by Common NameがONの場合はDLCのUUIDをCN/ Allowlistに記載する必要があります。



これにて一通りの設定が完了しました。




おわりに

個人的な感想としては証明書周りの設定はこの辺りまでが不慣れだと時間のかかる作業ですが、慣れればある程度素早くできるかと思います。ただ、DevOpsとの連携やSaaS特有の内部の詳細なエラーなどが確認しづらいという点がセットアップのハードルをやや上げているように感じました。その場合はDLC上で見ることのできるQRadar on Cloudとの接続のログやSelf Service Appから見れるQRoCのログを見るなどすると解決の糸口が見える場合があります。

DLCを使用することができれば自社の小さな拠点からもログを収集して、より全体を通しての可視性を向上することができるのでみなさまもぜひトライしてみてください。


参考資料：
https://www.nextdoorwith.info/wp/se/digital-certificate-encoding-extensions-difference/
https://www.ibm.com/docs/ja/qradar-on-cloud?topic=qradar-configuring-tls-over-tcp-communication
https://smile-jsp.hateblo.jp/entry/2021/02/09/150636