Macセキュリティのアップデートに時間がかかる理由とその対策

はじめに

IT部門の業務のなかで最も重要なものが、セキュリティアップデートの適用です。

脆弱性が発見され、パッチがリリースされるまでの期間は、組織にとって明確なリスクです。しかし、そのリスクはパッチがリリースされた時点で終わるわけではありません。むしろ、パッチが出たということは、緊急で対応が必要であるという事実を浮き彫りする出来事でもあります（重大度が高いほど、事態は一刻を争います）。

パッチがリリースされたら、組織のインフラの各所に広がるエンドポイントに速やかに展開しなければなりません。リスクを抑え、コンプライアンスを維持していくためには、必要なアップデートを早急に展開し、システム、アプリ、セキュリティのすべてを最新の状態に保つことが不可欠です。

もっとも、多くの中堅企業のIT部門が見ている現実は異なります。

中堅企業の場合、アップデートの展開に予想外の時間がかかることが少なくありません。アップデートの適用が終わるまでの期間はエンドポイントごとにまちまちです。さらに、エンドポイントによってはパッチが適用されないことすらあります。

アップデートの適用を終えるまでの期間の理想と現実にこのような差がある状態は、継続的なコンプライアンス確保という点で問題です。しかし、この事態は通常、IT部門の努力不足や不真面目な態度が招いたものではありません。従来の管理モデルが最新鋭の環境で求められる柔軟性や拡張性を備えておらず、現代の業務スピードに対応できないことが問題なのです。

IT部門がパッチの適用や各方面への連絡に精力的に取り組んだとしても、旧式のツールを使っている限りは限界があります。組織が成長・拡大していけば、いつかは越えられない壁に突き当たることになるでしょう。

アップデートがいつまでも遅いのはなぜか

Macのセキュリティアップデートとパッチの適用に一貫性がなくなる理由を把握するにあたっては、旧式のMDMのフローがどのようになっているかを理解しておくことが有益です。旧式のMDMで採用されているのは、コマンドベースのモデルです。つまり、（クラウドまたはオンプレミスの）サーバが管理対象デバイスに対してアクションを促す仕組みになっています。

このプロセスは、実務ではいくつかの段階に分かれており、それぞれがパッチの遅れを引き起こすリスクを抱えています。そこで、以下では旧式のMDMの典型的なパッチ管理フローを確認しながら、この点を具体的に見ていきましょう。

1. サーバからのプッシュ：MDMから最初のコマンドが送信されます。コマンドが失敗したり、遅れたり、デバイスに到達しなかったりした場合には、次回のコマンド送信までアップデートプロセスが停止することになります。
2. デバイスによるチェックイン：デバイスは自らの状態を常に報告しているわけではありません。一定間隔でサーバと通信することにより、新しい命令の有無を確認しています。これがチェックインです。このチェックインのタイミングでデバイスがオフラインであるなどしてチェックインの期間を逸してしまうと、予定どおりにアップデートを適用することができなくなります。
3. プロンプトによる確認: アップデートを承認するかどうかを確認するプロンプトが、通知アラートの形でユーザに表示されます。
   1. 承認：こちらが選択された場合には、アップデートがダウンロードされ、インストールが始まります。ユーザは、インストールが終わってシステムが再起動されるまでの間、作業を一時的に中断することを余儀なくされます。
   2. キャンセル：こちらが選択された場合には、単にアラートが消えるだけでなく、アップデートのフロー全体が停止します。ユーザが生産性を落としたくない場合に選択されることが多いのですが、アップデートがインストールされなくなる関係上、アップデートの展開が遅れることになります。

旧式のMDMでアップデートの展開を計画する場合に考慮が必要な事項はまだいくつかあります。具体的には以下のとおりです。

• 接続の要件：会社所有のデバイスが命令を受信するためには、多くの場合、会社のネットワークまたはVPNに接続している必要があります。分散環境おいては、この点が予測を難しくする原因になります。
• リアルタイムの可視性：IT部門がエンドポイントの健全性を明確に把握できなければ、アップデートが保留中なのか、ダウンロード中なのか、失敗したのかがわからず、対応が遅れるおそれがあります。
• 拡張性と柔軟性：コマンドは、まずサーバのキューに溜まっていきます。そのコマンドを、後から管理対象デバイスが処理するという流れです。しかし、コマンドの処理は遅延することが珍しくありません。それが積み重なれば、管理のプロセスは予測が困難になっていきます。

パッチの適用が遅れることによる本当のコスト

アップデートが遅れることによる影響は、時間とともに膨れ上がっていきます。

それはまるで、1つの事象が引き金となって影響が次々に連鎖していくドミノ倒しのようです。具体的には以下のとおりです。

• パッチ管理のコマンドが処理待ちの状態でキューに溜まっていく
• セッションのたびにキューが大きくなり、消費するリソースが増えていく
• 処理の遅延が積み重なり、さらに悪化していく
• デバイスにパッチが適用されない期間が想定以上に長くなる
• パッチを適用していないデバイスのリスクが高まる
• 既知の脆弱性のエクスプロイトの可能性が高まる
• コンプライアンス違反のデバイスが増え、ベースラインからの乖離が始まる
• セキュリティギャップが広がり、組織に規制違反のリスクが高まる
• IT部門が問題の火消しやユーザへのフォローアップに追われる

このような状態では、問題に先回りするアプローチは難しく、事後対応的なIT運用にならざるをえません。パッチ適用の遅れが原因となって脆弱性を抱えたままの期間が長引くため、同じ作業にいつまでも追われ続け、状況の改善に取り組むことができなくなります。

既知の脆弱性に対するパッチが遅れれば遅れるほど、リスクにさらされる期間も長くなります。中堅企業では、IT部門が500を超えるエンドポイントを管理することもよくあります。そのような状況で重要なのは、個々のインシデントではありません。組織全体で運用上のリスクが膨れ上がっていくことこそ、真の問題なのです。

宣言型デバイス管理（DDM）で何が変わるか

宣言型デバイス管理（DDM）は、現代の状況に対応した新しいエンドポイント管理を導入するものです。現代のデバイス環境に必要な柔軟性と効率性を兼ね備えており、パッチ管理に拡張性を実現します。

DDMでは、サーバのコマンドに頼るのではなく、デバイスが自らの理想的な状態を認識し、自律的に維持します。その流れを簡単にまとめると、以下のとおりです。

1. 条件の定義：IT部門が、MDMを使ってデバイスの理想的な状態（構成、OSのバージョンなど）を設定します。
2. 理想状態の伝達：コンプライアンスを確保した理想的な状態がどのようなものであるかを、DDMから管理対象のエンドポイントに伝達します。
3. 状態のレポート：デバイスの状態が変化した場合には、デバイスからレポートが届きます。そのため、アップデートのプロセスに継続的な可視性が実現します。
4. ポリシーの適用：デバイスがコンプライアンス状態から逸脱した場合には、コンプライアンス状態に自動で復帰します。この処理は、MDMサーバとは独立して発生します。

DDMは上記以外の点でも、セキュリティや運用効率の向上に寄与します。具体的には以下のとおりです。

• デバイスからユーザにアップデートを通知・案内したり、必要に応じてアップデートを強制実行したりできます。
• パッチのインストールを営業時間外に自動で実行するように設定できます（アップデート作業のユーザ依存度が大幅に低下します）。
• デバイス主導の仕組みを実現し、従来の業務フローの遅延の大部分を解消できます。

IT部門にとってのDDMの意義とは

DDMを導入すれば、最新鋭のパッチ管理戦略に移行できるという点はこれまでに説明してきたとおりです。しかし、DDMの効果はそれだけではありません。あらかじめ決められた条件が満たされた時点でデバイスが自律的にアップデートを実行するので、アップデートの展開が早くなる点も大きなメリットです。

デバイスのパッチが短期間のうちに完了し、業務効率が大幅に高まるほか、パッチの適用漏れが減ってセキュリティも強化されるのです。

管理対象デバイスのコンプライアンス確保に向けた作業など、繰り返し発生していた手作業を減らすことができるのも魅力です。さらには、DDMの基盤である可視性も高まります。エンドポイントの健全性をリアルタイムで把握できるようになるため、IT部門がデバイスの状況確認やアップデートの適用漏れに関するトラブルシューティングに追われる時間が少なくなります。

DDMは、究極的には組織が脆弱性にさらされる時間を短縮するためのものです。デバイスと組織のどちらのセキュリティ状態も強化できるのは、その結果の1つにすぎません。しかし、IT部門が火消し（事後対応）に追われることが減れば、戦略的な業務（予防的・積極的活動）に注力できるだけの時間の余裕が生まれます。その意味では、DDMはビジネス目標に合致した優れたソリューションを開発し、価値を創出していくための基盤であるとも言えるでしょう。