Jamf Compliance Editorを使用してMacをセキュリティフレームワークに準拠させてみる

jamf-compliance-editorブログバナー_サブ.png

セキュリティ対策は大事だけど大変...

企業のデバイスを管理していく上で、セキュリティ対策を避けて通ることはできません。
会社の規模や業種によって考えなければならないことは様々で、独自ルールを策定しなければならない場合もありますが、基本的にはなんらかのセキュリティフレームワークにもとづいて策定しているケースが多いのではないかと思います。

また、そもそも策定すること自体が中々に大変なことなのですが、それを運用し、かつ準拠しているか継続的に確認する、となると更にハードルがあがっていきます。

継続的な確認については、例えばJamf Protectを活用することにより「CISベンチマーク」の準拠状態を可視化することは可能ですが、準拠させるための設定はJamf Pro等のMDMによって定義していく必要があります。

また、CISベンチマークのドキュメントには各項目の設定方法についても記載されていますが、スクリプトを使用しなければならないことも多いですので、なんらかの仕組みで改善できればベストです。

そこで今回は、Jamf Compliance Editorを使用して効率的にMacをセキュリティフレームワークに準拠させてみようと思います。

はじめに

Jamf Compliance Editorは、macOSセキュリティ・コンプライアンス・プロジェクト(mSCP)にもとづいて公開されたアプリケーションです。
※mSCPの詳細については、以下のページをご参照ください。
GitHub - usnistgov/macos_security: macOS Security Compliance Project
macOSセキュリティ・コンプライアンス・プロジェクト - Apple サポート (日本)

Jamf Compliance Editorを使用することで、「CISベンチマーク(Center for Internet Security)」や「NISTサイバーセキュリティフレームワーク(National Institute of Standards and Technology)」といった、代表的なセキュリティフレームワークにデバイスを準拠させるためのガイドラインをGUIで簡単に作成することが可能になります。
※それぞれのセキュリティフレームワークの立ち位置については以下のページなどをご参照頂くと良いかと思います。
情報セキュリティに関する各種フレームワークの概要

準備

ということで実際に検証を行っていきましょう。
今回はmacOS 13 Venturaを搭載したMacをCISベンチマークのLevel 1に準拠させる際の流れを確認してみようと思います。
※CISベンチマークの概要やレベルごとの設定内容の違いについては以下のページ等をご参照ください。
CIS ベンチマークとは? - CIS ベンチマークの説明 - AWS
Center for Internet Security (CIS) ベンチマーク - Microsoft Compliance | Microsoft Learn

ステップ1:CISベンチマークを入手

まずは参考となるCISベンチマークを入手します。

(1) CIS Benchmarks にアクセスします。
(2) Apple macOSカテゴリからDOWNLOAD THE BENCHMARKを選択します。

001.png

(3) フォームに必要な情報を入力し、Get Free Benchmarks Nowボタンをクリックします。

002.png

(4) しばらくするとメールが届くので、Access PDFsボタンをクリックします。

003.png

(5) アクセスしたページから必要なPDFをダウンロードします。

004.png

CISベンチマークのPDFが入手できました。
※今回の検証では「CIS_Apple_macOS_13.0_Ventura_Benchmark_v1.0.0.pdf」を入手しています。
内容を見てみると、各項目の概要や目的、設定方法について詳細に記載されています。
(...とはいえ、通しで読破するのは中々にハードルが高いので、基本的には逆引き的に活用していく形になるかもしれません。)

ステップ2:Jamf Compliance Editorをインストール

次にJamf Compliance Editorをインストールします。

(1) Jamf Trusted Access Solution Center のEstablishing Compliance Baselines にアクセスします。
(2) DownloadからJamf Compliance Editor vX.X.X.tar.gzを入手します。
(3) tar.gzファイルを解凍し、Jamf Compliance Editor.appをアプリケーションフォルダに格納します。

Jamf Compliance Editorがインストールできました。
※今回の検証では「Jamf Compliance Editor v1.1.3」をインストールしています。

006.png

ステップ3:プロジェクトを作成

インストール完了後、Jamf Compliance Editorのプロジェクトを作成していきます。

(1) Jamf Compliance Editor.appを起動してCreate new projectを選択します。

007.png

(2) 任意のOSバージョン(今回はventura)を選択してCreateボタンをクリックします。
その際、プロジェクトの保存先を任意で選択してください。(macos_security-venturaというフォルダが作成されます。)

008.png

(3) CIS Benchmark - Level 1を選択してOKボタンをクリックします。

009.png

Jamf Compliance Editorの編集画面が表示されました。

010.png

ステップ4:ルールの確認

詳細な使用方法についてはJamf Compliance Editorのユーザガイドに記載されているため、今回は重要な部分に絞って確認していきます。

先程選択したベンチマークの内容にもとづいて、サイドバーのSectionsごとにセキュリティルールがウインドウ中央に表示されています。
※デフォルトではソートが「Sort - ID」になっていますが、CISベンチマークのPDFと照らし合わせながら確認していく場合「Sort - CIS Control」にしておくのが見やすいかもしれません。

ルールのタイトルを見ていくと、いくつかの項目に「$ODV」という文言が含まれています。
これは「Organization-Defined Values」の頭文字で、その名のとおり「会社独自で値を決めることができる」項目です。
※右上の検索フィールドで「odv」と入力すると、ODVが含まれるルールだけ表示されます。

012.png

今回は「2.10.1 Enforce Screen Saver Timeout(スクリーンセーバを開始するまでの時間)」をJamf Compliance Editorにデフォルトで定義されている20分(1200秒)から「5分(300秒)」に変更してみます。
※2.10.1については、ステップ1で入手したCISベンチマークの193ページに記載されており、20分以内で定義することが推奨となっています。
※ODVを定義する際「Customizing the ODV values is not recommended for CIS Benchmark - Level 1.」といったアラートが表示される場合がありますが、そのまま進めて頂いて大丈夫です。

014.png

ちなみに、スクリーンセーバを開始するまでの時間はMac上で選択可能な値に合わせる必要がありますのでご注意ください。

015.png

ODVを定義したルールはタイトルの横に「M」マークが表示されます。

016.png

その他にもODVが含まれるルールはパスワードポリシーなど重要な項目も多いため、一度確認しておくと良いかと思います。

ステップ5:ガイダンスの作成

ルールの確認が完了したら、その内容をエクスポートしていきます。

右下のCreate Guidanceボタンをクリックします。
今回のようにルールを変更している場合は、以下のようなダイアログが表示されます。

017.png

ここで定義する名称は、エクスポートされるフォルダや書類、あるいは後述するJamf Pro上のカテゴリ名など、いわばタイトルのようなものとして扱われます。
空白の場合は、デフォルトの「CIS_LVL1」が使用されますが、区別するために任意の文字列を記述しておくと良いかもしれません。(今回は「JCE_TEST」としています。)

OKボタンをクリックしてエクスポートが完了すると、以下のようなダイアログが表示されます。

018.png

VIewボタンをクリックすると、ステップ3で作成されたmacos_security-ventura > buildの中に「jce_test」フォルダが追加されています。

019.png

※内容についてはJamf Compliance Editorユーザガイドの14ページに記載されているとおりですが、改めて以下にも記載します。

chart01.png

020.png

「jce_test_compliance.sh」スクリプトを使用してMDMを使わずにローカルでセキュリティルールに準拠させることも可能ですが、今回はJamf Proを使用する想定なので次のステップに進んでいきます。

ステップ6:Jamf Proへのアップロード

いよいよ検証も大詰めです。
ステップ5でセキュリティルールをエクスポートしたことにより、右下のJamf Pro Uploadボタンがアクティブになっていますので、こちらをクリックします。

Jamf ProのURLとアップロード時に認証に使用するJamf Proユーザアカウントの情報を入力し、Continueボタンをクリックします。

021.png

※認証に使用するJamf Proユーザアカウントに必要な権限は以下のとおりです。

chart02.png

アップロードが完了すると、以下のようなダイアログが表示されますのでOKボタンをクリックします。

022.png

これによってJamf Pro上に定義される項目は以下のとおりです。
先程のダイアログにも記載がありますが、いくつかの項目については手動で定義する必要がありますので、続けて確認していきます。

chart03.png

追加作業①:スマートグループ

スマートグループを3つ作成します。(カッコ内はスマートグループの表示名です。)

1. macOS 13 Venturaを搭載しているMac(Computers running macOS Ventura

chart04.png

2. セキュリティルールに準拠しているMac(Ventura_JCE_TEST_Compliant

chart05.png

3. セキュリティルールに準拠していないMac(Ventura_JCE_TEST_NotCompliant

chart06.png

追加作業②:構成プロファイル

「Ventura_JCE_TEST」カテゴリに含まれている構成プロファイルのスコープをすべて変更します。
Jamf Compliance Editorユーザガイドでは、先程作成した「macOS 13 Venturaを搭載しているMac(Computers running macOS Ventura)」グループを選択していますが、稼働中のデバイスが含まれてしまう可能性があるため、今回は検証用デバイスのみ選択する形のほうが良いと思います。
(いずれにしても、地味にこの作業が一番面倒ですね...。)

023.png

追加作業③:ポリシー

ポリシーを2つ作成します。

1. 準拠状態の監査を行うポリシー(Ventura_JCE_TEST_Audit

chart07.png

chart08.png

2. 準拠していない項目を修復するポリシー(Ventura_JCE_TEST_Remediation

chart09.png

chart10.png

これでようやく準備完了です!(お疲れさまです!)
検証用デバイスにセキュリティルールが適用されるかどうか確認してみましょう。

適用確認

今回の仕組みの肝は、先程作成した「Ventura_JCE_TEST_Audit」ポリシーです。
このポリシーが1日1回、デバイスのチェックインが行われるタイミングで実行されることによりセキュリティルールの準拠状態を監査します。
そして、準拠していない項目がある場合「Ventura_JCE_TEST_Remediation」ポリシーによって修復する、...といった流れが繰り返される形になります。

基本的には構成プロファイルによって準拠が強制されている項目がほとんどですので、ユーザ側で変更可能な箇所は一部分なのですが、自動的に準拠状態が監査→修復されることによって管理者の手間を軽減することが可能になります。

それでは、具体的な挙動を確認していきます。
まず「Ventura_JCE_TEST_Audit」ポリシー実行前のデバイスの状況です。インベントリ > 拡張属性カテゴリ内は以下のような状態になっています。

024.png

次に検証用デバイスのターミナルで「sudo jamf policy」コマンドを実行するなど、チェックインが行われることによって「Ventura_JCE_TEST_Audit」ポリシーが実行されることを確認します。
その後改めてインベントリを確認すると以下のような状態に変化するかと思います。

025.png

Compliance - Failed Result List」に準拠していない項目、「Compliance - Failed Results Count」にその個数が表示されます。
※現状は、ルールの除外(Compliance - Exemptions)を行っていないため、Failed Result Listの項目数とFailed Results Countの数字は揃っているかと思います。

準拠状態が監査されていることが確認できたので、今後は修復してみます。
「Compliance - Failed Results Count」の個数が「0以上」のため、現在、検証用デバイスは「Ventura_JCE_TEST_NotCompliant」グループに含まれています。
この状態で再度チェックインが行われることによって、今度は「Ventura_JCE_TEST_Remediation」ポリシーが実行され、インベントリは以下の状態に変化するかと思います。

026.png

...あれ。まだ項目(system_settings_filevault_enforce)が残っていますね...。
実はちょっとした落とし穴なのですが、Jamf Compliance EditorではFIleVaultによるディスク暗号化の強制を行うことができません。
そのため、こちらについては別途、構成プロファイルを手動作成する必要があります。
※FileVault構成プロファイルの作成方法については今回は割愛させて頂きます。

作成したプロファイルによって暗号化した後、改めて「Ventura_JCE_TEST_Remediation」ポリシーを実行してみます。

027.png

...ようやく期待どおりの結果となりました!!
検証用デバイスがJamf Compliance Editorで定義したセキュリティルール(CISベンチマーク レベル1)に準拠しています。

補足①!注意ポイント!

最後の最後で申し訳ないのですが、Jamf Compliance Editor v1.1.3を使用してセキュリティルールを作成する際にODVを定義したルールがうまく適用されないバグ?が確認されています。
(2023年4月27日時点の情報です。Jamf社に確認したところ次のバージョンで修正予定とのことですので、検証を行って頂く際はJamf Compliance Editorのバージョンとユーザガイドの「Appendix 1 - Application Change Log」をご確認頂くようお願い致します。)

不具合の内容は以下のとおりです。
ステップ4で確認した「スクリーンセーバを開始するまでの時間」については、○○分のように「整数(Integer型)」で定義される必要があります。
ただし、プロファイルの内容を確認してみると「文字列(String型)」で定義されてしまっています。
※ODVを定義せず、Jamf Compliance Editorのデフォルト値のままアップロードした場合は正しくInteger型になっています...。

そのため、今回についても大変お手数ですが「Ventura_JCE_TEST-screensaver」プロファイルの「idleTime」キー部分を以下の画像のように、「<string>〇〇</string>」から「<integer>〇〇</integer>」に修正して頂ければと思います。

028.png

補足②ルールの除外

今回はすべてのルールを監査→修復する方向で進めてきましたが、Jamf Pro側でルールの除外を行うことも可能です。
※例えば、今回検証したCISベンチマークのレベル1ではAirDropの使用が禁止されていますが、一部のユーザのみ許可(監査しない)、といったケースで活用することができます。

設定方法はJamf Compliance Editorユーザガイドの29〜30ページに記載されていますが、流れとしては以下のとおりです。(上記のとおり、AirDropのみ監査しない形で進めていきます。)

(1) 以下の内容で構成プロファイルを作成します。(スコープは検証用デバイスのみ選択)

chart11.png

029.png

(2) (1)で作成したプロファイルを配布した後、AirDropの制限を行っている「Ventura_JCE_TEST-applicationaccess」プロファイルのスコープから検証用デバイスを取り除きます。
(3) 「Ventura_JCE_TEST_Audit」ポリシーを再実行します。その後改めてインベントリを確認すると以下のような状態に変化するかと思います。

030.png

「Compliance - Exemptions」にos_airdrop_disableが追加されています。
「Ventura_JCE_TEST-applicationaccess」プロファイルを取り除いたことにより、AirDrop以外(AirPlayレシーバーとパーソナライズされた広告)も許可されており「Compliance - Failed Result List」にリストアップされています。
しかし、「Compliance - Failed Results Count」は2とos_airdrop_disableを除いた数字になっていることが確認できます。

これによって検証用デバイスはAirDropのみ許可された状態になりました。

まとめ

いかがでしたでしょうか?
説明が非常に長くなってしまい恐縮です...。(ここまでお読み頂きありがとうございます。)

今回の検証では、あくまでもCISベンチマーク レベル1に含まれるすべてのセキュリティルールに準拠させる流れを確認しただけになっています。
その他のフレームワークに準拠させる場合や、ルールごとに要不要の判断やODVの定義など、お客様の運用想定に応じて個別に詰めていかなければならない部分も多く残っているかと思います。

デバイスのセキュリティ対策に関して現状抱えている課題や、その他気になることがございましたら、ご提案、サポートさせて頂ければと思いますので、ぜひお気軽にお問い合わせください!

記事は2023年4月27日現在の内容です。

おすすめ記事を見る