MDMのネクストステージ

JamfでDirector of Product Strategy（製品戦略部門ディレクター）を務めるKatie Englishが登壇し、まず今回のセッションについて、起承転結の「結」の部分から語り始めました。「このセッションの目的は、管理者の切実な問題をMDMが解決してくれるという期待を皆さんに抱いていただくことです」

まずはMDMの歴史から

「MDMプロトコルが導入される前は、管理可能なAppleデバイスはMacだけでした」とEnglishは話し始めました。「Casper Suiteに登録されたデバイスはまずローカルバイナリを取得し、そこに含まれたroot権限により、デバイスに関するデータを定期的に管理サーバに送信する仕組みになっていました。また、パッケージのダウンロードやローカルスクリプトの実行によって、ローカルクライアントにプログラムのアクションを指示することもできました。私たちはこれを『force pull（強制プル）』スタイルのデバイス管理と呼んでいました」

しかし、iPhoneの登場によりすべてが変わりました。Jamfがモバイルデバイス管理（MDM）機能の開発を始めたのはこの時です。「iOSの場合、ネットワークに物理的に接続されることはほぼ皆無で、さらにシステムアーキテクチャが大幅にサンドボックス化されています。このことから、デバイス管理スタイルは変わらざるを得なかったのです」

root権限を持つエージェントが定期的に管理サーバと通信する時代は終わり、プッシュ通信が使われるようになりました。

デバイスはAppleとの通信状態を保ちながらコアサービスにpingを送信し、設定の受信やコマンドのインストール、またはアプリのインストールが必要な際には、サーバがAppleにリクエストしてデバイスに通信させる仕組みになっていました。

MDMの基本

「これがMDMの基本で、Jamfの管理フレームワークを約13年近く支えてきた仕組みです」実際、Jamf Pro は現在もバイナリに関連したプルアクションとMDMプッシュコマンドを使用しています。

デバイス管理の未来

「もちろん、最初の頃と比べてプロトコルはかなり賢くなっており、コマンドやきめ細かな設定が山ほど存在します」とEnglishは続けました。

そこで注目すべきなのは、Appleが2021年に発表した「これからは宣言型デバイス管理の時代が来る」という言葉です。これは非常に決定的なことです。

「あの発表から1年が経ち、Appleはこの新しい宣言型管理プロトコルへの投資を続けています。そして、ありがたいことに従来のMDMと並行して運用することができています」

従来のMDMワークフロー

「先ほども申し上げたように、従来のMDMではデバイスがAppleと持続的に通信を維持することが必要で、コマンドやクエリを受信する際には、管理サーバーがAppleにリクエストしてデバイスに通信させる必要がありました」とEnglishは続けました。

例えば：

• 「OSをアップデートせよ」という内容のコマンドが出される
• それに続いて「現在のOSバージョンは？」というクエリが返される
• 正しくコマンドが実行されたことを管理者が確認するためのクエリが出される（「今はどんな状態か？」「明日もう一度チェックしてもいいか？」）

従来のMDMでは、コマンドが送信されたり完了したりすると管理者に通知が届き、デバイスから多くの情報を得ることができました。

「問題は、質問しなければこのような情報を得ることができないという点にあります」とEnglishは言いました。「しかも何度も、です。その結果、多くの重複した情報が何度も戻ってくることになります」複雑なコマンドや条件付きのワークフローを含むコマンドでは、情報の行き来が増えます。管理サーバに、その情報を解析し変更部分を割り出すようリクエストすると、結果としてコマンドやクエリが発生するからです。

宣言型デバイス管理の仕組み

宣言型デバイス管理は上記とはまったくの正反対で、設定した条件下でデバイスがどのように動作するかについて、はるかに詳細な指示を前もって送ることができます。この一連の指示とステータス報告機能を組み合わせることにより、デバイスの特定の値に変化が生じた際に管理サーバにアラートを出します。

「つまり、頻繁なポーリングや詳細なレスポンス、クエリに対してデバイスから帰ってくる報告に基づいた後手のMDMアクションに代わって、管理サーバが一連の指示を作成し、それをデバイスに送信するだけで、デバイスはMDMとほとんど通信せずに自律的にアクションを実行することができるのです」とEnglishは述べました。しかも、次に何をすべきかをデバイスに指示するために、管理サーバ自体がたくさんの計算に基づいたアクションを起こす必要がほとんどないのです。

「デバイスのデータに生じたほんの僅かな変化だけを頼りに、管理サーバは、修復ワークフロー、組織データへのアクセスの有効化や制限など、必要な追加処理を行うことができます」とEnglishは付け加えました。

Jamfは昨年、Jamf Pro 10.42で基本的な宣言とステータスアップデートを開始し、今年初めには同じ機能をJamf Schoolでも提供しはじめました。さらに、Jamfは次のステップとして、宣言によるソフトウェアアップデートを採用しました。これはすでにJamf Proで利用可能になっており、Jamf Schoolでもまもなく提供が開始されます。

Englishは、ソフトウェアアップデートのワークフローを提示しながら今後の方向性について説明するとともに、この機能をさらに推し進めるAppleの機能についても触れました。

• クライアントサイドの通知
• あらかじめ設定された適用タイミングの前にユーザ自身がアップデートを実行する機能
• ローカルクライアントのロジックを使用してユーザ自身がアップデートのタイミングを設定できる機能

Englishは、数年前まで管理者はポリシーやスクリプトコマンドを使ってsoftwareupdate バイナリを呼び出していたということに触れた上で、Appleが宣言型デバイス管理の機能をこれからも強化していくことを強調しました。初代M1 Macの登場後、このバイナリの挙動は変わりました。認証には、MDMのブートストラップトークンと最新OS、そしてローカルユーザ主導でアップデートを行う場合はユーザパスワードが必要です。

「スクリプトやroot権限を持つローカルエージェントによってトリガーされる無人ポリシーは、基本的になくなりました」とEnglishは述べました。

次なるAppleの進化

Englishは、この変化が新たなトレンドの始まりである可能性を示唆します。「特定のバイナリへのプログラムを用いたアクセスは、MDMに任せるべき、またはエンドユーザ自身が管理者権限を与えられて行うべき、という考えが一般的になるにつれて、今後も廃れていくことが予想されます」とEnglishは続けます。

「特にセキュリティの観点からも、Appleがこのような選択をする理由は明白です。例えば、ユーザが誤ってマルウェアが含まれたアプリをダウンロードしてしまったと仮定しましょう。アプリがインストールされると、アプリの権限を変更したり、アプリのサンドボックスを超えたアクセスを行う目的で、ペイロードがアプリバンドル外のローカルバイナリにアクセスしようとします。そのためにパスワードを入力する手間によって、悪意あるバイナリアクションが実行されるのを防ぐことができるかもしれません」

さらに、カーネル拡張や、エンドユーザがMDMの介入なしにそれを自らインストールする負担に関しても、業界で同様の変化が見られています。

「管理アクションを行うための適切な管理ツールが今後ますます必要になっていくはずです」とEnglishは言います。「恐らく、これまでスクリプトで行ってきた多くのことをMDMで行うようになると思います」

管理の程度

この予測をさらに裏付ける証拠として、Englishは、MDMの一部の機能性と可視性が意図的に制限された、ユーザ登録によるBYODワークフローを挙げました。「管理ツールである程度のことはできますが、ユーザのデータが無視され、ユーザの選択が管理コマンドによって勝手に上書きされることはありません」

では、アカウント主導のワークフロー、コンシューマーデバイス、そしてMDMの未来から、どのような結論を導き出すことができるのでしょうか？ここで鍵となるのは管理対象Apple IDです。これにより、多くの新たなワークフローが利用できるようになり、またそれらの機能性も進化します。

業界では今後もApple IDによる管理対象が拡大していくだろうとEnglishは考えています。

「デバイスに適用される管理の量と種類は、必然的に複雑になりつつあります」とEnglishは説明しました。「以前は、フルに管理するか、全くしないか、のどちらかでしたが、今は違っています。エンドユーザも事情にかなり精通してきており、個人データと業務データの衝突に抵抗を覚えたり、MDMはエンタープライズのニーズと消費者の要望の両方を叶えるべきであると考えたりしています。

Trusted Access

Trusted Accessもまた、後手に回るのではなく宣言的なアクションを行うものとして、使い勝手と安全性の面で優れたものへと進化していくであろうとEnglishは考えています。

JamfのTrusted Accessは、管理ソリューションとセキュリティソリューションを組み合わせることで、信頼できるデバイスを使用する認可されたユーザだけが、組織のリソースに適切にアクセスできるようにするものです。「Jamfはこのコンセプトを非常に真剣に捉えています。関連ページをまだご覧になっていない方は、ぜひチェックしてみてください」とEnglishは観客に伝えました。

「管理者は、セキュリティに対して後手に回ることに慣れています」とEnglishは続けます。「宣言型管理が成熟し、より多くの任意のインタラクションを提供するようになれば、管理者がコンプライアンス状態を定義するだけで、デバイスはそこから逸脱できなくなります」

宣言的管理よってMDMの機能が強化されることで、デバイスのセキュリティは底上げされ、ユーザは重要な条件が変更された際により迅速にそのことを知ることができます。

次なるJamfの進化

「AppleがMDMを進化させ続ける中、Jamfがどのようにしてその機能性を管理者の問題解決に変えていくのかについてお話しします」とEnglishは続けました。

Jamfは今年も、Appleから多くのチャンスを得ました。

「Trusted Accessがデバイスの管理およびセキュアな運用のための包括的なアプローチであることはすでにお話ししましたが、より具体的な例として、今年リリースが予定されている最新機能の『Return to Service』コマンドについて挙げたいと思います」

Englishは、このコマンドが今後どのような形で変化し、Jamf ProとJamf Schoolのワークフローをどのように拡張するかについて参加者に説明しました。

さらに、Self Serviceのような既存ツールも新たな機能拡張を得て、さらに使いやすく効果的なツールへと進化しました。

その先の未来：変化を恐れないこと

「宣言型デバイス管理が今後の方向性であることは間違いありませんが、私自身の仕事にはそれほど影響はないと思います。WWDCでは大きな発表が沢山ありましたが、私には直接関係のないものばかりです」

— UX Researchのインタビューに答えたJamfカスタマー

「気持ちは痛いほどわかります」Englishは述べました。「変化は現場に混乱をもたらすこともあり、率先して変化を避ける組織も少なくありません。私自身、変化を嫌う管理者でしたし、すべてをスクリプトで行うことにまったく問題を感じていませんでした。ですが、今ではすべての管理者が変化に対する抵抗を払拭できるようになることを願っています。なぜなら、MDMの進化を見ていると、変化というのは決して悪いものではないと思えるからです」

懐疑的な、あるいは変化を恐れるApple管理者でも、MDMの進化に価値を見出すはずだとEnglishは考えています。

EnglishはMDMが以下の形で進化すると考えています。

• セキュリティの向上（宣言型管理で開封時からコンプライアンスに準拠するよう設定し、プログラムによる低レベルバイナリの扱いを制限する）
• よりネイティブな管理（宣言に基づくエンドユーザのインタラクションが可能になる）
• 時間とともに有用性がアップ（MDMのパワフルな基盤が宣言型デバイス管理でより強化される）

困った時の味方 = Jamf

Jamfは、ソフトウェアアップデートやReturn to Serviceと同様に、MDMを活用した問題解決を支援しており、管理者がより迅速に新機能を採用できるよう、アーキテクチャを最適化しています。さらにJamfは、組織独自の基準に合わせたAppleデバイスの管理とセキュアな運用も可能にします。