Kandji、ぶっちゃけどうなのよ？

はじめに

どーもみなさんこんにちは。ねもてぃです。

ついに日本にもやってきましたねー！Kandji！！！

海外では数年前からAppleデバイスを管理するMDM製品として台頭してきていたKandjiですが、正式に日本展開が始まりました。

Appleデバイスの管理といえばJamf Proという製品がほぼ一強で独走していましたが、いよいよ比較対象になり得る製品が来たな、という感じです。

まだまだ国内では情報が少ないと思いますので、実際に触ってみた感想を持って「Kandji、ぶっちゃけどうなのよ？」について書いてみようと思います。

※2024年12月時点での情報となります。

Kandjiとは

• 公式Webサイト：Kandji

Kandjiは、企業向けのAppleデバイス管理（MDM）プラットフォームで、Mac、iPhone、iPad、Apple TVなどのデバイスを一元的に管理・セキュリティ強化するためのツールです。特に、デバイスのセットアップ、アプリの配布、ポリシーの適用、セキュリティ更新などを自動化でき、IT管理者の負担を軽減します。また、ゼロタッチデプロイメントや高度な監視機能を提供し、企業のセキュリティ基準を維持するのに役立ちます。Kandjiは、クラウドベースでスケーラブルなサービスを提供し、エンタープライズ規模での導入にも適しています。 ~ChatGPTに聞いてみた~

はい、そうですね。Jamf Proと同じくAppleデバイスの管理に特化したMDM製品です。EDR機能を利用できるプランもありますがここでは触れないこととします。

カタログスペックだけでみるとリモートワイプやゼロタッチキッティング、アプリや設定の配布といった基本的な機能は備えているため、Jamf Proと比較しても変わらないように見えます。

ざっくりとした比較表

みんな大好き比較表です。

当然、自社にフィットするかどうかは要件や状況次第なのであくまで雰囲気です。(筆者の主観も入ってます)

こんなところでしょうか。もう少し機能カットでも見てみます。

こちらもざっくりなので実際のユースケースにおいて要件を満たせるかどうかはトライアルなどで確認することを推奨します。

あるあるですが◯×レベルでみると、どちらも基本的な管理においては対応していると言えます。

Kandjiのいいところ

ここからはKandjiを触ってみていいな、と思ったところについて挙げていきます。

設定手順など画像付きでわかりやすい

設定マニュアルとして用意されているもののほとんどにスクリーンショットや項番が振られており、道なりに進めていくだけで使い始めるまでのほとんどの設定が完了します。(実際にそうでした。)

マニュアル例：Configure the Automated Device Enrollment Library Item

手動でデバイスをKandjiに登録する場合のページも画像付きで手順の案内があるため、管理者が別途作成する必要もありません。

Assignment Mapsが非常に強力

このAssignment MapsがKandji最大の特徴と言ってもいいかもしれません。

ブログ記事：Assignment Maps: The Revolutionary New Way to Manage Apple Devices

基本的にはこのAssignment Mapsを利用して必要な設定やアプリを割り当てていきます。特徴として、

• 構成の条件分岐などをチャート的に設定できる Macのチップタイプ(Intel/Appleシリコン)
• OSバージョン
• Tag情報
• ユーザーグループ
• ユーザーの部署
• などなどを条件分岐に使用可能

デバイス検索と組み合わせることによってどの構成が割り当たるかを追うことができる

という点となります。この機能によってどのデバイスにどのような設定がどのような条件によって割当たっているかが一目でわかるため、前任者がいなくなってしまった場合などの状況把握もしやすいのでは、と思いました。

上述のブログ記事で紹介されているこちらの動画がわかりやすいかと思います。

Managed OSのユーザー体験がGood

OSアップデートの管理、悩みますよね？いろいろ触ってきましたがKandjiのManaged OS機能が一番構成が楽&ユーザー体験も良いと思いました。

ブログ記事：Introducing Managed OS for iOS, iPadOS, and tvOS

強制するかSelf Serviceでインストールするかも選べるし、

リリース後いつまでに強制するかも構成できます。

設定した内容に対して具体的に強制される日時を表示してくれるのもGoodです。

エンドユーザーにはこのような形で通知が行われます。

実際はメニューバーに常駐するKandjiメニューバーアプリから表示が行われます。

Auto Appsによる自動アップデートとメニューバー表示が優秀

Auto Apps(Kandjiが用意しているアプリカタログ)にあるアプリであれば自動アップデートの構成が可能です。基本的にはバックグラウンドで自動更新する運用になるかと思いますが、Kandjiメニューバーアプリから通知し、促すこともできます。

アプリとは異なりますが手動登録などでFileVaultディスク暗号化のリカバリーキーを再発行する場合もこのKandjiメニューバーアプリから再発行手順を通知することが可能です。

ParametersによるCISベンチマークなどへの対応設定が容易

なにかと話題になりがちなCISベンチマークですが、実装しようと思うとドキュメントを読み込み、構成プロファイルやスクリプトを組み合わせて試行錯誤する必要があります。Kandjiでは構成プロファイルだけでなくスクリプトで実装しなければならない項目までテンプレートが用意されているため、スクリプトの検証や調整を行う必要がありません。

もちろん実運用環境で実装すべき項目かどうかの精査や検証は必要かと思いますので、慎重に検討ください。

※要は内容よくわからんけどテンプレにあるから設定しちゃう、とかはトラブルの元になるのでご利用は計画的に、という話です。

• 構成プロファイルベースの項目

• スクリプトベースの項目(Parameters)

CISベンチマークに関する項目については何度か実装したことがあるのですがこれがまぁ大変なんです・・・

特にスクリプトを利用する項目を設定していくのに多大な労力が必要なので最初から用意されているのはGoodと思いました。

ただ注意点としてこのParametersについてはAssignment Map内の条件分岐に組み込むことができず、ひとつのAssignment Mapでひとつの構成しか設定できません。つまり、特定の部署だけCIS Level 2、他はLevel 1とする、としたい場合は条件分岐ではなくAssignment Map自体をもうひとつ作成し、割り当てる必要があります。この分岐が増えそうな場合は、せっかくのAssignment Mapの特徴である可視性が薄れてしまうので注意が必要です。

デバイス名の設定が容易

これも比較的悩むことが多い項目です。基本的にスクリプトで対応することが多いのですがKandjiにはテンプレートが用意されており、ユーザー名、シリアル番号、モデル名など命名規則の要件が合えば設定が簡単です。

※テンプレートにない資産管理番号など特殊なルールを利用したい場合は別途スクリプトで実装する形になるかと思います。結局。

Custom Script実行時のAudit Scriptが優秀かもしれない

Custom Scriptを実行する際の設定として「Audit Script」が構成可能です。このAudit Scriptは本命のスクリプトを実行する前に特定の条件に合致しているかをチェックし、合致した場合のみ実行する、といったことができます。Kandjiの標準機能としてAuto Appsにあるアプリケーション以外はアプリが削除された場合にのみ再インストールを実行する、といった構成はできないのですがAudit Scriptを組み合わせることである程度は実現が可能そうです。(Netskopeの公式配布手順がこの形でした。)

具体的なユースケースによる、としか言えなくはありますが多少応用が効きそうな設定項目かな、と感じた次第です。

Kandjiの微妙なところ

こちらではKandjiを触ってみて微妙だな、と思ったところについて挙げていきます。

※すべてKandji社にフィードバック済みなので改善期待してます！！！

設定を追加するための操作がめんどくさい

アプリや設定を追加する場合にKandjiが用意してくれているリスト(Library Items)から追加するのですが、Auto AppsとしてKandjiが事前に用意してくれているアプリリストが膨大にあり、設定したい項目まで辿り着くのにそこそこスクロールが必要です。しかも前半にAuto Appsの一覧があるため、設定系の項目は最下部までスクロールが必要です・・・

一応カテゴリフィルターやOS種別フィルターはあるものの、ひとつ設定を追加すると設定済みLibrary Items一覧画面に戻ってしまい全表示に戻ってしまうのでいちいち設定していくのがめんどくさいです。

気になる設定を開いた際に、「あれ、これじゃない、違ったや」と戻ろうとした時も同様です。(別タブで開けるようになると嬉しいです・・・)

また、Auto Appsでさまざまなアプリを追加することができはするのですが、自動アップデート設定などはひとつひとつ行う必要があるのでこれもまためんどくさかったです。

このあたりは初期設定時の産みの苦しみではあると思うので運用フェーズ乗ってしまえばそこまで気にならないかもしれません。

※これが比較表のところに記載したKandjiが「シンプルで直感的なUI」と評されているものの、微妙だな、と思ったポイントです。

Auto Appsを利用したアプリ配布において同じタイトルで複数設定ができない

Auto Appsを使う場合にはなりますが、例えば同一アプリで自動アップデートを有効にする設定と有効にしない設定、といった2パターンをアイテムとして追加することができません。アイテムとして追加ができない=Assignment Mapの条件分岐で構成を分けることができない、ということになるので異なる構成を行いたい場合はAuto Appsではない方法を検討する必要がありそうです。

まぁ、これはユースケース次第だと思います。

すみません、こちらはラベルを設定することで複数作成することが出来ましたので修正いたします。ツッコミありがとうございました！

表示がmacOS/iOS/iPadOSで共通なので見にくいかもしれない

macOSだけしか管理しないのにiOS/iPadOSに関する設定項目も全て一覧に表示されます。逆もまた然りです。いろいろ設定を追加していく上でそこそこノイズになるなぁと思いました。例えばパスコードポリシーを設定しようとした場合、まずは一覧としてMac/iPhone/iPadに対する設定がすべて表示されます。もちろん削除は可能ですがMacにだけ設定したいのに同一設定項目として表示されるのは少しイマイチな感じがしました。(個人の感覚です)

確かにAppleの構成プロファイルの仕様としては各OSで同じパラメータ/キーを使用しているのでわからなくもないですが・・・このあたりは好みになるかな、と思います。

カスタム構成プロファイルを利用する場合、mobileconfigファイルとして用意する必要がある

一部の管理設定やサードパーティアプリに対する設定などでカスタム構成プロファイルを使用するケースがあります。

確かにほとんどのMDMがこの場合、利用者が自前でmobileconfigファイルを用意/作成し、アップロードする形としています。これには設定内容を記述したplistファイルと呼ばれるものを作成し、mobileconfigファイルに変換する、と言った手順が必要なのですがこれがまた手間でして・・・

内容を変更したい場合もこの手順が発生するのでちょっとした変更をしたい時、うまくいかなくて修正したい場合などにプチストレスになります。

何を隠そうJamf Proであればplistファイル自体のアップロードどころかテキスト直打ちでも作成/変更できてしまうのでこの辺りはストレスフリーなのです。せめてplistファイルのアップロードはできて欲しいなぁと思いました。

ディレクトリ統合を行う場合のユーザー一覧取得範囲の調整が難しい

Kandjiを効果的に活用するためには基本的にIdPとディレクトリ統合を行い、ユーザー情報の取得およびデバイスとの紐付けを行うのがベストプラクティスになるかと思います。

ただこのディレクトリ統合をドキュメントに従い構成するとシステムアカウントなども取り込まれてしまい、ユーザー一覧が雑多になってしまう、という印象を受けました。この辺りの取得範囲をIdP側のグループなりなんなりでいい感じにできるといいな、案内があるといいなと思いました。

ディレクトリ統合以外の連携もそうですが、連携時に利用するアカウントはシステムアカウントが推奨なのか管理者のアカウントでも良いのか、や最小必要権限の案内などが明示されていると嬉しいです。

Microsoft Device Complianceの条件は構成(調整)できない

Entra ID 条件付きアクセスを利用するためのMicrosoft Device Compliance統合が実装されています。

ただ、Kandjiではこの連携をテナント単位で有効にするか利用しないかの2択しか構成できません。そのため特定の条件に合致したデバイスのみ有効にする、といったことができません。

Kandjiの設計思想においてはAssignment Mapsで構成した設定は必ず適用される、ユーザーが設定を変更したとしても次回チェックイン時に自動修正される、といった考えのもととなるので一度準拠したものは準拠し続けるという想定ではあると思いますが、そもそも適用対象自体のコントロールができないのは少しユースケース的にキツいことがあるかもしれないな、と思いました。

また、何かしらの理由でうまくいかなかった場合に手動で再実行/再登録を行う、などの有効なリカバリー方法がなく、やり直しが必要となった場合のトラブルシュートに不安が残ります。(今のところ一度登録できてしまえば安定しているような印象ではありますが)

現状のドキュメントではなにかあったらサポートに連絡してください、という案内となっているのでこのあたりも後々充実してくることを期待しています。

Okta Device Trustも同様に条件分岐は絡めづらい

Okta Venturesに参画しOktaから出資を受けていることもありOktaとの連携に力を入れているKandjiではありますが、Okta Device Trustの肝となるOkta VerifyアプリにManagedフラグを適用するかしないかの2択しか構成できないことが少し懸念です。Okta Verifyに対して複数の設定を構成できないということもあり、複雑な条件分岐に対応するのは難しそうだなという印象ではあります。Kandjiに登録されている=Trust値を満たしているという前提のもとの運用になるのでこの前提をどこまで許容できるか、と言った観点も必要になるかもしれません。

上述の通り、Kandjiに登録されている=定義したセキュリティ設定は必ず適用されていると言うのが設計思想ではあるのでデバイスのセキュリティポリシーから逸脱している状態は基本的にない、という考えがベースではあるかと思います。

まとめ

• Kandjiのいいところ(触ってみて良かったところ) 使い始めるまでの設定手順がわかりやすく、学習コストが少ない
• Assignment Mapsの視認性が良く、構成状況がわかりやすい
• OSのアップデート管理や設定のテンプレートなど、痒いところに手が届いている

Kandjiの微妙なところ

• 管理コンソールのUIについて、優れた部分もあるがストレスに感じる部分がないわけではない
• 複雑な要件や条件分岐に対応する必要がある場合、手段がないわけではないがシンプルさが失われてしまい本末転倒になる可能性がある
• まだまだ公開情報が少なく、サポートに頼らないとトラブルシュートが難しい可能性が高い

おわりに

ひとまずファーストインプレッション、ということで書き連ねてみました。まだまだ細かい思ったことなどはありますが、ひとまずこの辺にしておきます。

情報もユースケースも少ない製品ではありますが、要件があえば全然戦える製品だと思いますし、今後情報のアップデートもどんどん進んでいくかと思います。

macOSの管理がまだできていない方、Intuneの管理では厳しくなってきた方、ぜひ実際に触って検討してみてください。もちろん相談も受け付けてますのでお気軽にお声がけいただければと思います！

それでは！