端末管理をIntuneに集約してアクセス制御を導入してみた
平尾幸春
この記事はリクルートICT統括室 Advent Calendar 2023 21日目の記事です。
はじめに
初めまして、リクルートの平尾です。
本記事では当社のゼロトラスト化への取り組みについて、Microsoft IntuneとEntra IDによる端末管理の統合とアクセス制御の導入（苦労）話をご紹介します。
現在Intuneの新規導入や他MDM基盤から移行を検討されている方向けの内容となります。
なお途中の挿絵につきましては作成時期の関係でHAADJなど旧名称が残存しておりますが、適宜読み替えて頂けますと幸いです。
取り組みの背景
いわゆるコロナ禍前から皆さんも散々取り組んでこられたであろう働き方改革の一環として、当社でも「場所やネットワークに依存しない執務環境の実現」というのが大きな目標でした。
一方で、社内データ資産の保護のためのセキュリティリスク低減も並行して課題となっていました。
その中でもSaaS利用の拡大を見据えた認証高度化や会社データ保護を目的に、当社ではEMMやアクセス制御の導入を検討することとなりました。
端末識別とアクセス制御の方式検討
実際に検討し始めたところ、その時点ですでに他のプロジェクトにてMicrosoft Entra hybrid joined（旧HAADJ）が推進されておりました。
また、ライセンス的にもIntuneを導入する与件はクリアしていましたので、まずは教科書通りに社給端末をIntune管理下におき、そのうえでデバイス識別での条件付きアクセスをかけていこう！となりました。
ところが、これまた別のプロジェクトにて「1年半後には社内ネットワーク上のファイルサーバーを廃止しSharePointやOneDriveなどを使用してもらう！」ということがわかりました。
つまりあと1年半以内に、最低限SharePoint領域にはアクセス制御を導入する必要がありました。
端末管理基盤の統合
まずはアクセス制御における端末の識別方式の検討から着手しました。
社給端末として貸与しているiPhone/iPadは約60,000台あり、これらは別のMDM製品に管理されていました。
Windowsは約58,000台あり、すでにMECM管理となっていました。
あくまで喫緊の目的はアクセス制御の早期導入であり、条件付きアクセスにて「社給端末ならフルアクセス、それ以外の端末なら制限あり」を実現するため、以下の方針としました。
iPhone/iPad：
- 払い出し済みの端末はユーザー自身でのIntuneアプリのインストール/セットアップを通してIntuneデバイス登録（MDMの移行）を実施してもらう。
- 新しく払い出される端末は管理者側にてABM連携を実施し、最初からIntune端末として強制的に登録/構成させる。
Windows：
- MECM共同管理構成（MECMとIntuneの両方の管理下に置く）を有効化することでIntuneデバイス登録させ、様々なWindows端末利用条件をみながらMicrosoft Entra hybrid joinedでもIntune準拠でも識別できるようにしておく。
上記方針によってIntune準拠済み端末（またはMicrosoft Entra hybrid joined端末）を社給端末と定義できますので、これで条件付きアクセスを導入することが可能となりました。
アクセス制御の導入匙加減
端末の識別方式を決めましたので次はアクセス制御の匙加減、つまり非社給端末からのアクセスに対してどこまで制限を加えるか、を検討しました。
当初は「社給端末なら社内データ資産へはフルアクセスにするけど、非社給端末ならアクセス拒否！」を実現しようとしました。
社給端末であればセキュリティ面において脆弱性対応などを施しておくことができますし、ガバナンス面においても情報漏洩の監視などができますが、非社給端末が相手だと会社としてそれらの対策を施すことが困難だからです。
ところが、過去を掘り起こすと認可制で、主にパートナーを対象とした非社給端末の業務利用を受容していた実績がありました。
他にも様々な業務コラボのケースがあったので、「いきなり非社給端末をアクセス拒否にしたらビジネスが止まっちゃうよ！」という指摘が内部から上がりました。
そこでまずはアクセス拒否ではなく、アクセスにおいてダウンロードを制限するという方針となりました。
先ほどの識別条件と紐づけるとこんな感じです。
施策の推進方法
ここまで整理がついたら、あとは実現に向けた推進施策です。
Windows端末は「社給端末なのにダウンロードNG」となる事象を避ける必要があります。
当時Microsoft Entra hybrid joined化は推進中であったものの、まだ未完了状態の社給端末が残存していたため、これらのMicrosoft Entra hybrid joinedを促進させることにしました。
未Microsoft Entra hybrid joined状態、PRT未取得状態かどうかをサインイン時に状態確認させ警告ポップアップを表示させるツールを作って配布しました。
読み手には「詳しいことはわからないけれど、指示されたことをやらないと業務に支障が出るんだ！」ということが伝わればOKです。
ただ事じゃないとわかったうえで、何か困りごとが起きたときは大抵はユーザー側が問い合わせてくれるので、これは効果がありました。
同様に、iPhone/iPadもMDM切替はユーザーに作業を実施してもらう必要があります。
しかしこちらもユーザーにはとっては耳慣れず、「MDM？なにそれおいしいの？」となってしまうことを想定し、作業を実施しないと業務影響が出ますよ！というメッセージを含めて全社広報のうえ定期的に状況を追跡することにしました。
未対応者には個別に連絡し、さらには上長も巻き込んでMDM切替を推進しました。
アクセス制御（ダウンロード制限）の発動、切り戻しの発生（その1）
さて、これでようやくアクセス制御導入への下準備が済みました。
仮に予期せぬ端末ユースケースが出ても、一時的にダウンロードできないだけですからすぐに業務が止まるわけではありません。
万が一何かが発生しても対策前進ができるだろう！とアクセス制御を発動しました。
ところが切り戻しが発生しました。
アクセス制御を発動したところ、「Power Automateが動かないぞ！業務影響出てるぞ！」と叫び声が上がってきました。
一体何が起きたのか、原因と対策を説明します。
そもそもPower Automate接続のコネクタ認証は、「どんな状態の端末で認証を実行するか」で取得するトークンが変わってきます。
社給端末条件(Microsoft Entra hybrid joined状態)での認証ならフルアクセス、非社給端末条件(Microsoft Entra hybrid joined実施前)での認証ならダウンロード制限を受けたトークンが発行されます。
今回発生した事象というのは、Microsoft Entra hybrid joined実施前にPower Automateコネクタ認証を実施したWindows端末がダウンロード制限を受けたトークンを取得し、その後Microsoft Entra hybrid joined化したものの、古いトークンを保持し続けてしまっていたため、条件付きアクセスを発動した際にダウンロード制限を受けてしまったというものでした。
この場合は、Microsoft Entra hybrid joined化だけではなく、Power Automateコネクタの再認証が必要でした。
そこで、急いで追加広報や操作マニュアルの展開を実施し、対応しました。
アクセス制御（ダウンロード制限）の発動、切り戻しの発生（その2）
今回の切り戻しにて我々はひとつ学びを得ました。
そして当初想定していた以上にPower Automateが広く使われ、技術系部門に留まらず営業系でもかなり活用されていることを認識することもできました。
さて、周知をやり直し、問い合わせ経路もさらに立てつけたので、アクセス制御を再発動しました。
…再び切り戻しが発生しました。
アクセス制御を発動したところ、「SharePointサイトが見られなくなったぞ！業務影響出てるぞ！」とまた叫び声が上がってきました。
ここでも何が起きたのか、原因と対策を説明します。
Webサイト作成などに携わったことのある方ならすでにお気づきと思いますが、サイト構成パーツによっては読み込み時にダウンロードが実行されます。
そのため非社給端末からのアクセスだと正しく表示されない、もしくはサイト自体がアクセス拒否となる事態が発生しました。
各サイト側で加工してもらうとか、SharePoint管理者に各サイトの構成パーツにDL制御フラグを設定してもらうとか、手段はあるにはありました。
しかし対象サイトは軽く数えただけでも200以上あり、タイムリミットを考慮すると到底対応できるものではありません。
では我々は何をしたのか？
まず非社給端末からの社内SharePointサイトへのアクセスはルールとしてNGであると社内規程があったことで、「そもそも非社給端末からのアクセスはNGとしているから対応はしない」と方針決定することができました。
ただし業務上影響が発生しているので速やかに社給端末を調達したい！というケースを考慮し、端末を受け取るまでの時間制限付きでユーザーID単位での特例的な除外制度を設けました。
今回の取り組み成果
度重なる切り戻しを経てようやく到達した現在の姿です。
青線が今回の挑戦による成果です。
社給端末は全てIntune登録させたことでデバイス識別を使えるようになりました。
したがってEntra ID条件付きアクセスが効果的に使えるようになり、原則は社給端末のみ会社SharePointへのフルアクセスを許可するということができるようになりました。
併せてMAM（Mobile Application Management）もMCM（Mobile Contents Management）も導入可能になりましたので、EMMへの移行自体は成功したと言えるのではないかと思います。
さいごに
ここまでMicrosoft Intuneとアクセス制御の導入までご紹介しましたが、冒頭で言及した「ゼロトラスト化」という目線ではまだ始まりにすぎません。
せっかくIntuneへ端末管理基盤を統合していく足掛かりができましたので、ここからは脱MECM管理やAutopilot導入、Microsoft Entra hybrid joined（旧HAADJ）からEntra Joined（旧AADJ）へのシフトによって管理制御の統合や効率化を図っていきたいと思っています。
ユーザーにとっては端末セットアップの難易度が下がり、管理側にとっては端末管理構成がよりシンプルになります。
またSharePoint以外のサービスに対するアクセス制御や、コンプライアンスポリシーと連動させた、よりリアルタイム性の高いアクセス制御を推進していこうと思っています。
たとえば社給端末であっても最新の状態でなければ危険因子と見做してダウンロード制御するようなやり方です。
そしてせっかく様々な端末データが今までよりも簡単に見られるようになったので、そのデータを活用してユーザー問い合わせ対応の品質を上げたり、いっそ問い合わせられるより先に不調に気づいてあげられるようなサポートの形を模索しているところです。
以上が当社の端末管理統合と、アクセス制御の導入のお話でした。
皆様の取り組みにおいてなにかちょっとでも参考になれたら幸いです。
リクルートICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿していく予定です。
もし興味があれば、ぜひ他の記事もあわせてご参照ください。