こんにちは。SCSK 中山です。
少し前に発表のあったDevice Postureのアップデートでプロファイルでレジストリキーの値や稼働しているプロセスを条件として設定できるようになりました。
弊社アカウントにもアップデートが適用されましたので、今回は設定・動作検証をしてみたいと思います。
と、その前に、、
Device Postureという機能を軽く説明しておきます。
Device Postureとは
Device Postureとは、端末の状態をチェックし属性を付与する機能です。付与した属性に対してポリシーを設定することで、要件を満たさない端末をネットワークへ接続させないといったコントロールが可能になります。
詳細については、別途記事を書いておりますので、こちらをご覧ください。
Device Postureは設定できる条件がいくつかあり、よく使われるところだとクライアントのセキュリティソフトのインストール有無、セキュリティソフトのバージョンのチェックがありますが、今回のアップデートでは条件として端末のレジストリキーの値や指定したプロセスが稼働しているかが指定できるようになったという感じです。
合わせてこの記事では触れてませんが、MacOS向けに「Property List」での指定も追加されております。
詳しくはCatoのナレッジをご確認ください。対応OS/Cato Clientのバージョンも記載されております。
Creating Device Posture Profiles and Device Checks
それでは早速設定・検証をしていきたいと思います。
実施手順
レジストリキーの設定
① CMAから、「Access」 >「 Device Posture」>「Device Checks」の「New」から新規のポリシーを作成します。
②「General」>「Device Test Type」で「Registry Key」を選択します。
③ 「Criteria」にポリシーの内容を記載します。
- OS：Windows
- Registry Key Path：<設定したいレジストリーのパス>
- Key Value Name：<設定したいレジストリキーの名前>
- Key Value Data：<設定したいレジストリキーの値>
イメージとしては、「Registry Key Path」と「Key Value Name」でレジストリキーのフルパスを作る感じです。
例えば、以下画像のレジストリキー(HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate)の値で条件を作成したい場合、CMA側の設定はこんな感じになります。
◆レジストリエディターの画面
◆CMAの設定画面
レジストリキーに何かしら値が入っていたら、、、という条件の場合は「Key Value Data」で「Any Value」を選択してください。
④ ポリシーを作成できたら、「Device Posture Profiles」より、新規でプロファイルを作成し、③で作成したポリシーを紐づけます。
プロセスの設定
① レジストリキーの設定と同様に新規ポリシーを作成します。
②「General」>「Device Test Type」で「Running Process」を選択します。
③「Criteria」にポリシーの内容を記載します。(以下設定はWindowsの場合)
- OS：Windows
- Process Name or path：<設定したいプロセスのフルパス or プロセス名>
- Signer Certificate Thumbprint：<証明書の拇印>
以下は検証の際にAWSのssm-agentで設定した際のCMAの画面です。
プロセス名、拇印の確認方法
・ プロセス名
「タスクマネージャー」よりプロセスの「プロパティ」を開くことで確認できます。
フルパスで指定したい場合には、同じようにプロパティ画面から確認できます。
CMAには 場所+プロセス名+ファイルの種類で記載すれば設定できます。
上記の場合、「C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe」と指定する感じです。
サービスとして稼働している場合には、各サービスのプロパティ画面から直接フルパスを確認できます。
・ 証明書の拇印の確認方法
① プロセス名の確認手順と同様にタスクマネージャからプロセスのプロパティを開きます。
② 「デジタル署名」タブを開き、署名を選択し、詳細を開きます。
③「証明書の表示」し、証明書の「詳細タブ」を開きます。
詳細の中に「拇印」という項目があるので、その値をCMAの「Signer Certificate Thumbprint」に記載します。
Device Postureの設定自体はこれで完了です。
「Client Connectivity Policy」や「Internet Firewall」、「WAN Firewall」で作成したプロファイルを指定することで、対象のデバイスをコントロールすることができます。
実際にやってみた
レジストリキーを指定する場合、プロセスを指定する場合、どちらも検証してみました。
レジストリキーはWindows Updateを無効化しているデバイスをCatoに接続できなくするような設定で検証してみました。
CMAの各設定はこんな感じです。
◆ Device Checks
「Default」はレジストリエディター上で(規定)となっている箇所の時に使用します。
◆ Device Posture Profile
◆ Client Connectivity Policy
今回設定しているレジストリキーはWindows Updateの自動更新を有効にする場合は「0」、自動更新を無効にする場合は「1」を設定するような項目になっていて、このポリシーでは自動更新が有効の場合、ポリシー１が適用されCatoに接続できますが、自動更新が無効の場合はポリシー２が適用され、接続できなくするような設定になってます。
クライアント側のレジストリキーはこんな感じで設定しました。
値を1にして自動更新を無効にしてます。
これでいざCato Clientの接続を試みると、、
エラーが出て接続できませんでした。
こんな感じでWindows Updateを無効化している端末をCatoに接続できないようにできました。
次にプロセスを指定する場合を検証しました。
操作ログ取得系のアプリがバックグラウンドで動いているイメージで、そのアプリを停止させるとCatoに接続できなくするような想定で検証しようと思いましたが、操作ログ取得系のアプリが検証環境になかったので、適当にバックグラウンドで動いているアプリを指定して検証しました。
CMAの各設定はこんな感じです。
◆ Device Checks
◆ Client Connectivity Policy
◆ Client Connectivity Policy
基本的にはレジストリと同様でプロセスが稼働中はポリシー１が適用され、プロセスが停止中の場合はポリシー２が適用され接続できないような設定になってます。
クライアント側のプロセス稼働状況はこんな感じです。
設定した「amazon-ssm-agent」が稼働しております。
この状態で接続をすると、、
プロセス稼働中はもちろん接続はできます。
Catoに接続した状態のまま、「amazon-ssm-agent」のプロセスを停止して放置します。
～5分後～
接続が切れてしまい、再接続もできなくなりました。
本環境では、Device Postureのチェック間隔を5分にしていたため、検証では再チェックのタイミングで接続が切れました。
このように定期的にチェックが入るため、接続時のみプロセス稼働させておき、接続後にプロセスを落とすということはできないようになってます。
また、上記含めて「Client Connectivity Policy」でCatoに接続させるか否かを制御しておりますが、Internet Firewall、WAN FirewallでもDevice Postureの設定を使った制御も可能です。
一応こんな感じです。
◆ インターネットFW
「Action」部分を載せてませんが、「BLOCK」に設定していて、「Device Posture Profiles」の条件に該当する通信は全拒否するようにしてます。Profileは先程のプロセスで検証したものと同様。
◆Cato Client
「Client Connectivity Policy」で制御していないので、Cato自体への接続はできてます。
Catoに接続 かつ 「amazon-ssm-agent」のプロセスが稼働している状態でインターネットにアクセスしようとすると、、
今回は条件該当する場合に通信をBLOCKするので、アクセスができないようになってます。
もちろんプロセスを止めると、条件に当てはまらないので、通常通りインターネットにアクセスすることができました。
余談ですが、ふと思いつきで複数ユーザでログインした状態でプロセスの判定を検証したところ、片方のユーザがプロセス起動している状態であれば、もう一方のユーザはプロセスを立ち上げてなくても、Catoに繋げてしまったので、”Device Posture”というだけあって、Catoに接続しようとしているユーザのプロセスだけではなく、端末全体のプロセスを見ているっぽいです。
誰かしらプロセスを立ち上げていればすり抜けられちゃうみたいなので、ユーザ単位で起動しているプロセスを条件に指定する場合には、注意が必要そうです。
ユースケースを考えてみた
レジストリ/プロセスを指定して制御するユースケースを考えてみたいと思います。
まず、レジストリから。
レジストリは設定できる内容が多いため、できることはたくさんあると思います。
私が知っているレジストリの知識の範囲で例を挙げてみたいと思います。
まずは検証のようにWindows Updateを無効にしている端末の接続を不可にする場合ですかね。
パッチ管理ソフトでの制御をしている場合は不要かと思いますが、パッチ管理ソフトを導入していない場合、ルールは決めていてもなかなか強制はできず、セキュリティ基準を満たしていないPCが接続してしまう可能性があります。このような端末をレジストリで条件指定することによって、社内NWに接続できないようにできるのかなと思います。
パッチ回りだと適用されているセキュリティパッチを指すレジストリキーがありそうなので、そのキーを条件指定することで、セキュリティパッチを適用していないをCatoに接続させないということができそうかなと思ったのですが、毎回KB○○に新規で作成されるみたいで、毎月条件を変更するといった運用が必要そうなので、やろうと思えばできそうですが、運用を踏まえると現実的ではなさそうです。
他だと会社から支給されたPCに何かしらのフラグが設定されていたりしたら、会社PC or 個人PCとで識別できますかね。Cato Clientは正規のユーザであればログインできてしまうので、個人のPCにClientを入れてCatoから社内NWに接続できてしまいます。これに対し、フラグにあたるレジストリキーを条件にすることで、会社PCのみCatoに接続でき、個人PCは接続させないとかができそうです。
次にプロセス。
こちらも検証でやろうとしていた管理系のアプリ/プロセスを条件にして操作ログの取得できない端末は社内NWに接続させないとかは結構有用な気がします。
あとは、アンチウイルスソフトのプロセスを指定するとかもありな気がします。従来の設定でもアンチウイルスソフトを設定する方法がありましたが、あくまでインストールされているか、バージョンはポリシーを満たしているかをチェックしているだけで、実際に起動しているかを条件にしているものではないです。なので、社内ルールに則りインストールはしていても、実際にはアプリを止めているとかもできてしますので、プロセスの方で条件するのも良いかもです。
ただ、プロセス全般に言えることかもですが、バージョンアップ等でプロセス名が変わってしまうと設定変更が必要なので、注意が必要かもです。アップデートごとに検証をするという運用もセットかもですね。
まとめ
今回はアップデートで追加されたDevice Postureのレジストリキー/プロセスの指定での制御を検証してみました。
レジストリキー/プロセスを条件を指定できることになり、設定にあたりOSの知識も必要になってきましたが、今までの条件より比較的柔軟にデバイス制御ができるようになったかと思います。これまでにデバイス制御を断念したことがある方も今回のアップデートを機に再検討してみては如何でしょうか。