社給端末制限の緩和でコストをかけずに、安全かつ柔軟性のあるリモートワーク環境の提供を！：Microsoft 365で実現するクラウド時代のセキュリティ（2）

本稿は、Microsoft 365に含まれる「セキュリティ関連機能」にスポットを当てるシリーズです。公式ドキュメントからは読み取れない便利な機能を、日本マイクロソフトの技術営業チームが紹介します。今回は「社給端末制限」について再考し、クラウドをより良く活用するためのベストプラクティスを紹介します。

[PR／＠IT]

PR

　「Office 365」を活用し、いつでも、どこでも、どんなデバイスからでもコラボレーションやコミュニケーションができるようになれば、テレワーク／リモートワークを通じた働き方改革でビジネスのスピードを速め、生産性を高めていくことができます。一方、Office 365の利用に当たっては、そのデメリットについてあまり議論されることなく、「社給端末制限」が日本企業の中で広く一般的に求められています。

　本稿では、日本マイクロソフトの技術営業チームが普段顧客と接する中で見聞きした、厳密な社給端末制限で発生する運用コストや失われてしまう柔軟性を明らかにし、“ソフトな社給端末制限”で運用コストをかけずにセキュアにクラウドを活用するための実装方法を紹介します。

なぜ社給端末制限が求められるか？

　日本企業で社給端末制限が求められる背景としては、おおよそ以下のような理由が挙げられます。

●サイバーセキュリティ観点

　認証を強固にする多要素認証の一要素としてデバイスも確認し、外部からのサイバー攻撃の成功確率を低減したい。

●情報セキュリティ観点

　社給端末については、必要なセキュリティ製品を組み込んでおり、ログの取得による監視や操作制限などにより、内部犯行含めた情報漏えいに対して、一定の対策がなされている。そうした端末からの接続に限定することで、情報漏えいのリスクを低減したい。

●労務管理・運用観点

　管理監督責任上、個人の金銭負担が伴い、管理状態が把握できない個人の端末での業務遂行について、企業から推奨することも、許可することもできない。

　また、BYOD（Bring Your Own Device：個人端末の業務利用）についてはガイドやポリシーも策定していないので、個人端末については接続を許可しないことであらかじめ可能性を排除し、IT部門の管理責任およびサービス・サポートの範囲を社給端末に明確に限定しておきたい。

●上層部・関係者から理解を得るため

　社給端末制限であれば、上層部・関係者に説明しやすく、クラウドの利用開始に当たって合意が得られやすい。

一般的な社給端末制限の実装

　Microsoft 365環境で社給端末制限を実施する場合、大きく2つの方法が検討されます。

［方針1］証明書認証

　Active Directoryフェデレーションサービスなど、外部の認証サーバを用意してOffice 365に接続する際、認証サーバで証明書を用いた認証を実装する。

　また、デバイス証明書は、オンプレミスのActive Directoryに参加した端末に証明書サービスを利用して自動配布するか、別途外部サービスを利用して、MACアドレスなどでフィルタリングしながら、限定した端末に配布する構成とする。

　ただし、証明書による認証は、ブラウザや先進認証に対応したアプリのみで利用でき、POP（Post Office Protocol）／IMAP（Internet Message Access Protocol）などの古いプロトコルや、Office 2010以前のOfficeでは利用できないので、これらをパスワードのみの認証で例外的に許可するかどうかを別途検討する必要がある。

［方針2］条件付きアクセス

　Azure Active Directoryの「条件付きアクセス」機能でOffice 365に接続する際、オンプレミスのActive Directoryで管理されていて、Azure Active Directoryに同期されたデバイス（Windows 10／Windows 8.1／Windows 7）や、「Microsoft Intune」（以下、Intune）で管理され、ポリシーに準拠したデバイス（Windows 10／Mac／iOS／Android）であることを要求する。

　また、Intuneに各ユーザーがデバイス登録する際、シリアル番号、IMEI番号などでフィルターをかけ、指定された端末のみを社給端末として登録できるように制限する。必要に応じて、Windowsに対して「Windows Autopilot」や、iOSに対して「Apple Device Enrollment Program」などを併用し、社給端末の登録を自動化する。

　なお、Windows 10の登録をユーザーに実行させる場合は、シリアル番号での登録制限はできない点（IMEI番号を指定した登録制限は可能）と、MDM（Mobile Device Management）としてIntuneの利用が前提となるため、特にiOS／Androidでサードパーティー製MDMとの併用は不可となる点は留意が必要。

　方針1の証明書認証も、方式2の条件付きアクセスも、端末を識別するといった意味では同等ですが、方式2の条件付きアクセスの方だけが、企業が定めたポリシーにデバイスが合致しているかどうかまでを確認しているので“より本質的”です。

社給端末制限の実際

　Microsoft 365環境下で社給端末制限が実現できるとはいえ、厳密にITに落として考えるとさまざまな実装、運用構築に当たっての課題があります。実際に見聞きした中でも、以下のようなコストやデメリットが挙げられます。

　もちろん、これらの実装や運用に当たって、各SIベンダーからサービスが提供されているので、彼らに任せることもできますが、そのトータルコストや将来的な移行コストなども事前に考慮しておくことが重要です。

●初期構成・展開コスト

　社給かどうかをIT的に厳密に判断しようとすると、シリアル番号、IMEI番号といった端末固有の情報を収集し、登録する作業が発生します。

　また、厳密にデバイスを認証しようとすると、デバイスに対して発行した証明書を使った認証を実装することになりますが、証明書そのものの取得コストや、別途用意する認証サーバの構築コストが発生します。

　さらに、証明書発行を社給端末に限定するためには、MACアドレスを収集し、MACアドレスで証明書発行をコントロールするなどの制御も必要になります。

●運用コスト

　端末の更改、故障による交換、証明書の有効期限切れなどと併せて、端末固有情報の登録・更新作業が発生します。証明書を利用していた場合には、認証サーバの運用や保守、デバイス単位の証明書の発行および年次の証明書の更新に関わる作業コストも発生します。

　また、何か設定に問題があれば、社給端末なのに接続できないといった問い合わせも発生し、その対応でのコストや、ITサービスに関する満足度の低下などの影響も無視できないものとなります。

●機会損失コスト

　端末の登録作業が完了しない限りはクラウドに接続できない構成となるため、新規端末を調達したり、端末の故障などで代替機を用意したりした場合に、端末が手元にあったとしても、クラウドが利用できるようになるまで数日のリードタイムが必要となります。

　特に、国内外の出張時に、予期せず端末が故障すると、出先で何もできなくなってしまい、ビジネスの継続性に大きな影響が出ます。

　日本国内の本社地域を中心に、目の届く範囲で運用していればリードタイムは短縮できますが、タイムゾーンが異なりフェースツーフェースで顔を合わせられない海外拠点などへのサービス提供を考えた場合、端末情報の更新・登録などでかなりのリードタイムが発生することが考えられます。

●サービス拡張の制限

　社給端末制限は、MDM環境や認証サーバに依存する部分が大きく、今後、それら環境の入れ替えや統廃合を検討する際に、厳密な社給端末制限は移行コストや難易度を高める原因になります。

　また、当初はPCのみを対象とした運用だったところから、スマートフォンやタブレットなどへ社給端末の拡大を考えたり、メールのみを対象としたサービス提供から、「SharePoint Online」や「OneDrive for Business」「Microsoft Teams」「Yammer」など利用するサービスの拡大を考えたりする際、動作確認や端末の追加登録、証明書の追加発行、ポリシーの見直しなど、さまざまな作業が発生します。

　さらに、企業の吸収・合併や、海外進出に合わせた新拠点の設立時などで、多大な統合コストが発生します。

ルール強制に当たっての方法論

　社会には多くの法令やルールがあります。それらのルールの強制に当たっては、得られる効果や効率、リスクに応じて、さまざまな強制方法が存在します。現実社会を例に取ると、以下の表のようなルールの強制段階があり、厳密にルール順守のチェックをリアルタイムに行っていなかったとしても、継続的なルール違反を排除できることが経験的に分かります。

	ルール強制の方法	適用例
	（1）ルールの明示のみ	公園でのボール遊びの禁止
	（2）監視員による不定期チェック	違法駐車禁止
	（3）監視員による定常監視	クレジットカードの不正利用の検知
	（4）監視員による全数チェック	航空機搭乗時の持ち物検査
	（5）自動化されたリアルタイムの全数チェック	高速道路のスピード違反検知

　日本においては、ことITやシステムの話となると完璧が求められ、その制御は上記表の（5）のように社内システムであっても、いかなる例外もなく、適切に取り扱われていなければならないという思い込みがあります。

　しかし、実際にITで厳密に実装し、硬直したシステムを作り上げるよりは、上記表の（1）のように具体的な使い方やルールだけを明示して柔軟に運用する方が、この変化の激しい時代には、より適していることも多くなってきています。この部分で柔軟で実効性にフォーカスした緩和された実装を選択できるかどうかが、日本と欧米との生真面目さの差でもあり、生産性の差としても現れています。

社給端末制限の緩和＝ソフト社給端末制限

　日本企業においては、リスクが少しでも残る場合、そのリスクを適切に査定した上での合理的な判断が行えず、極力リスクを避ける傾向にあります。実際、社給端末制限においても生真面目に厳密に実装して、コスト増の負のスパイラルにはまってしまうことがあります。

　しかし、リスクを一つ一つ適切に査定してみれば、厳密にITで社給端末制限を実装しなくても、Microsoft 365の機能をうまく活用することで、ほぼ全てのリスクに対して適切に対処できることが分かります。以下に現実的な落とし所として、緩和された、「ソフト社給端末制限」の設定を紹介します。

●Office 365にEnterprise Mobility＋Security E3を追加して実装できるAzure Active DirectoryおよびIntuneによる設定例

（1）　Azure Active Directoryの条件付きアクセスの設定で、利用規約の機能を用いて、「Office 365関連サービスの利用に当たっては、社給端末での接続に限ること」および、「違反があれば、上司含めて懲罰の対象であること」を明記し、デバイスごとに四半期に一回利用規約の同意を取得し、同意した日時を記録する

（2）　デバイス単位に利用規約の同意を求める場合、Azure Active Directoryへデバイス登録が必要となるが、デバイス登録時に多要素認証を要求する構成とする（*1）

（3）　Intuneアプリ保護ポリシー（*2）により、Windows 10／iOS／Androidでのデータの扱いを規定し、企業データは暗号化して保持、個人用アプリやサービスにはデータを持ち出せないように制限する

（4）　Intuneアプリ保護ポリシー（*2）により、iOS／AndroidについてはMAMによる条件付き起動で、脱獄またはルート化されたデバイス上でのOffice 365アプリの起動を禁止し、ユーザー／グループごとにOffice 365アプリを利用できるデバイスの種類や製造元を社給端末の種類に応じて限定する（*3）

（5）　Azure Active Directoryの条件付きアクセスの設定で、利用規約の同意に対応しないPOP（Post Office Protocol）／IMAP（Internet Message Access Protocol）などの古いプロトコルの利用を社内に限定するか禁止する（*4）

（*1）MDM管理と切り離してAzure Active Directoryへのデバイス登録のみ行うことも可能。また、iOSはMicrosoft Authenticator、AndroidはIntuneポータルサイトのアプリを利用してデバイス登録を行う。ただし、各デバイスは、1つのAzure Active Directorにしか登録できない
（*2）Intuneアプリ保護ポリシーは、Intuneによるデバイス管理は必須ではない。サードパーティー製MDMとも共存可能であり、MDMの移行過渡期にもこのソフト社給端末制限は実装可能
（*3）Androidの場合、アプリの利用を特定の製造元の端末に限定することが可能。iOSの場合には、現在以下のサイトでまとめられている72種類の型に従った限定が可能
https://support.hockeyapp.net/kb/client-integration-ios-mac-os-x-tvos/ios-device-types
（*4）以下のドキュメントを参照のこと
・方法：条件付きアクセスを使用して Azure AD へのレガシ認証をブロックする

利用規約について同意を求める画面《クリックで拡大します》

利用規約の同意を定期的に要求する設定と、同意についてのログ《クリックで拡大します》

IntuneでのMDM管理でなくても利用可能なアプリ保護ポリシーによるOffice 365アプリが起動できる条件の指定《クリックで拡大します》

　ソフト社給端末制限の重要なポイントは、厳密に端末固有のIDを確認することはせず、明文化した罰則を伴う利用規約の提示で個人用端末の接続禁止を求めている点です。このような実装にすることで、端末を1台1台管理するという手間を省き、それでいて実質個人用端末の接続をほぼ排除できます。また、ビジネスの遂行上やむを得ず、必要性が客観的に主張できる場合には一時的に個人用端末の接続を認めるなど、利用規約の中身次第で、より柔軟性を持った運用も可能になります。

ソフト社給端末制限で引き続き得られる効果

　本稿の冒頭で社給端末制限が求められる背景や目的をまとめましたが、ソフト社給端末制限においても引き続きこれらの目的を達成できます。

●サイバーセキュリティ観点から社給端末制限に期待すること

　認証を強固にする多要素認証の一要素としてデバイスも確認し、外部からのサイバー攻撃の成功確率を低減したい。

■ソフト社給端末制限で実現する効果

　Azure Active Directory登録時に多要素認証を要求するので、ID／パスワードのみの認証試行による攻撃の影響を排除可能。

　なお、端末登録時に多要素認証を求めたとしても、日常的に多要素認証を求めるわけではないので利便性を損ねることもない（一方で、デバイスの識別に用いられるシリアル番号、IMEI番号、MACアドレスなどは端末のプロパティ情報にすぎず、偽装は不可能ではない。

　また、デバイス証明書も正規の端末から、エクスポート不可の設定であったとしても抜き出せるツールが存在するため、社給端末の確認が必ずしも強固な認証方法とはいえない）。

●情報セキュリティ観点から社給端末制限に期待すること

　社給端末については、必要なセキュリティ製品を組み込んでおり、ログの取得による監視や、操作制限などにより、内部犯行含めた情報漏えいに対して、一定の対策がなされている。そういった端末からの接続に限定することで、情報漏えいのリスクを低減したい。

■ソフト社給端末制限で実現する効果

　Intuneアプリ保護ポリシーは、社給端末や個人所有端末によらず、一律適用され、内部不正含めた企業データの安易な漏えいはソフト社給端末制限でも防止可能。

　また、端末内の企業データは、社給端末や個人所有端末によらず、暗号化され、PINで保護され、ワイプ可能な状態にできる。

●労務管理・運用観点から社給端末制限に期待すること

　管理監督責任上、個人の金銭負担が伴い、管理状態が把握できない個人の端末での業務遂行について、企業から推奨することも許可することもできない。

　また、BYODについてはガイドやポリシーも策定していないので、個人端末については接続を許可しないことであらかじめ可能性を排除し、IT部門の管理責任およびサービス・サポートの範囲を社給端末に明確に限定しておきたい。

■ソフト社給端末制限で実現する効果

　利用規約の同意で、会社支給の端末のみ接続を許可するなど明示的なルール、サポート範囲、制限事項、罰則などにも言及した上で、同意を得ることが可能。

●上層部・関係者から理解を得るため

　社給端末制限であれば、上層部・関係者に説明がしやすく、クラウドの利用開始に当たって合意が得られやすい。

■ソフト社給端末制限で実現する効果

　本稿を紹介することで、ソフト社給端末制限でも厳密な社給端末制限と同等の効果が得られる点を説明可能。

ソフト社給端末制限で本当に大丈夫？

　ソフト社給制限で制御しきれないケースには、どういったものがあるでしょうか？　機能上は以下のケースで、個人用端末の利用が可能となってしまいます。

本人が明確に意図を持って、社給端末と同じ型のデバイスを用いて、利用規約に同意した上で、利用規約に反する形で、個人所有の端末で接続する場合

　上記のケースでは多要素認証が伴うので、本人は否認することができず、デバイスを故意に接続して、利用規約に同意したという記録が残るので、そういった不正が見つかれば、直ちに是正を促すことが可能です。

　ただし、そもそも個人所有の端末を接続したところで、脱獄またはルート化したデバイスの利用は排除でき、データの安易な漏えいは防止できているので、個人所有の端末が接続できたとしても、データ漏えいのリスクは限定的です。

　また、このように利用規約に反する形で、故意に個人所有の端末を接続するのが、仮に、100人に1人いるかいないかだとして、その1人を排除するために、証明書の配布やシリアル番号、IMEI番号の登録など、価値を生まない管理作業を組織全体に強いること、また、それによってビジネス上適切な端末の利用に多大なリードタイムが必要となり柔軟性が失われてしまうことが、果たして合理的でしょうか。

　Office 365の利用検討に当たっては、安易に厳密な社給端末制限を課すのではなく、実効性とリスクを適切にアセスメントして、ソフト社給端末制限での実装で、運用負荷をかけず、低コスト体質な制御を検討してみてもよいのではないでしょうか。