柱②デバイス——端末の状態をアクセス条件につなぐ
レッスン4:柱②デバイス——端末の状態をアクセス条件につなぐ
このレッスンで学ぶこと
- デバイスの柱が、アイデンティティの柱とどうつながっているかを理解する
- デバイスポスチャという考え方を説明できる
- 端末の健全性を示す代表的なシグナルを整理できる
- デバイス信頼をアクセス判断に結びつける設計を理解する
- 管理外端末の扱いと、私物端末をポリシーで受け入れる設計を把握する
前回のレッスンでは、アイデンティティの柱を扱い、条件付きアクセスの判断材料として「端末の状態」というシグナルが登場しました。今回は、そのシグナルの中身を掘り下げ、デバイスの柱として独立に扱います。「この利用者は誰か」だけでなく、「この利用者が今使っている端末は、信頼できる状態にあるか」を確かめることが、この柱の役割です。アイデンティティの柱とデバイスの柱は別々に成熟度を測りますが、実際の判断は、この 2 つの柱の情報を組み合わせて初めて意味を持ちます。
なぜデバイスの柱が必要か
正しい利用者が、正しいパスワードと多要素認証でログインしてきたとします。アイデンティティの柱だけを見れば、これは正当なアクセスです。しかし、その利用者が使っている端末が、セキュリティパッチの適用されていない古い OS で動いていたり、マルウェアに感染していたりしたら、どうでしょうか。正当な利用者の資格情報を経由して、危険な端末が組織のリソースに触れることになります。
利用者の身元と、利用者が使っている道具の状態は、別々に確認する必要があります。この「道具の状態」を確認する役割を担うのが、デバイスの柱です。中核メッセージの 5 番目、「アクセスを判断する材料は、認証だけでなく端末の状態にもある」は、この柱の存在理由をそのまま言い表しています。
もう少し具体的な場面で考えてみましょう。ある社員が、正しいパスワードと多要素認証で、いつも使っている社給の端末からログインしてきたとします。ここまでは、アイデンティティの柱だけで十分に評価できる、健全なアクセスです。ところが、同じ社員が、空港のカフェで、私物の古いノート PC から、OS のセキュリティパッチが半年以上適用されていない状態でログインしてきたとしたら、状況は一変します。利用者の身元は同じでも、アクセスに使われている道具の信頼性がまったく異なるため、同じ強さでアクセスを許可してよいとは限りません。デバイスの柱は、この違いを条件付きアクセスの判断に反映させるために存在します。
デバイスポスチャという考え方
デバイスの柱の中心にある考え方が、デバイスポスチャです。ポスチャとは、もともと「姿勢」を意味する言葉で、ここでは「端末が今、どのような健全性の状態にあるか」を指します。
デバイスポスチャは、一度確認したら終わりというものではありません。端末の状態は、OS の更新、マルウェア対策ソフトの稼働状況、設定の変更などによって、日々変化します。ある時点では健全だった端末が、翌週には脆弱性を抱えた状態になっているかもしれません。デバイスポスチャは、こうした変化を継続的に把握し、その時点でのアクセス判断に反映させるための考え方です。
💡 ポイント デバイスポスチャは、レッスン 1 で確認した NIST SP 800-207 の 5 番目の原則、「すべての保有資産と関連資産について、完全性とセキュリティ状態を監視・測定する」を、端末という単位で具体化したものです。一度きりの検査ではなく、継続的な監視が前提になります。
健全性シグナル
デバイスポスチャを評価するために使われる、代表的な健全性シグナルには、次のようなものがあります。
- OS の更新状況:セキュリティパッチが最新の状態まで適用されているか。既知の脆弱性が放置されていないかを示します
- ディスクの暗号化:端末の紛失や盗難が起きた場合に、内部のデータが読み取られないよう、ディスク全体が暗号化されているか
- 監視ソフトの稼働:端末の挙動を監視するソフトウェアが、正常に稼働しているか。この領域を担う仕組みとして EDR という名称がよく使われますが、本コースでは特定製品の比較には踏み込みません
- 管理対象かどうか:その端末が、組織の管理下にあるかどうか。管理対象であれば、組織側から遠隔での設定変更やロックが可能ですが、管理対象外の端末では、これらの制御が及びません
これらのシグナルは、単独で「合格・不合格」を判定するものではなく、組み合わせて総合的な健全性を評価するために使われます。OS が最新でも監視ソフトが停止していれば健全とは言えませんし、管理対象であっても暗号化が無効化されていれば、リスクは残ります。
flowchart TD
D1[OS の更新状況] --> DP[デバイスポスチャ]
D2[ディスクの暗号化] --> DP
D3[監視ソフトの稼働] --> DP
D4[管理対象かどうか] --> DP
DP --> DT[デバイス信頼]
📝 補足 「監視ソフトが動いているかどうか」を確認する仕組み自体は、比較的新しい技術ではありません。従来型のセキュリティソフトも、稼働状況を確認する対象になります。デバイスポスチャという考え方の新しさは、こうした情報を一箇所に集約し、アクセス判断にリアルタイムで反映させる点にあります。
シグナルをどう集めるか
健全性シグナルの集め方は、端末が組織の管理対象かどうかで大きく変わります。管理対象の端末であれば、端末上で常時稼働するソフトウェアを通じて、OS のバージョンや監視ソフトの稼働状況を、比較的詳細に取得できます。一方、管理対象外の端末では、そこまで踏み込んだ情報は取得できず、ブラウザ経由で確認できる範囲の、限られた情報にとどまります。
この違いは、「管理対象端末には詳細な条件を、管理対象外の端末には確認できる範囲の条件を」という、デバイスの柱の設計方針に直結します。管理対象外の端末に対して、取得できないはずの情報を条件に組み込もうとすると、ポリシーそのものが機能しなくなります。自社がどこまでの情報を取得できるかを正しく把握したうえで、条件を設計することが前提になります。
デバイス信頼とアクセス判断の結合
健全性シグナルから導き出される、その端末が現時点でどれだけ信頼できるかという評価を、デバイス信頼と呼びます。デバイスの柱の目的は、このデバイス信頼を、アイデンティティの柱で扱った条件付きアクセスのポリシーと結びつけることにあります。
レッスン 3 で紹介した設計例を思い出してください。「社外からのアクセスだが、端末は管理対象で健全な状態にある」という条件に対しては、追加確認のうえで許可するという対応を示しました。ここで判断材料になっているのが、まさにデバイス信頼です。同じ利用者、同じ社外からのアクセスであっても、端末が管理対象で健全であれば通し、管理対象外で健全性が確認できなければ拒否する、という差をつけられます。
利用者の身元だけを見て判断していたときと比べて、判断材料が一つ増えることで、条件付きアクセスの精度は大きく向上します。デバイスの柱が成熟すればするほど、アイデンティティの柱の判断も、より精緻になっていく関係にあります。これは、レッスン 2 で確認した「柱同士は互いの成熟度を補い合う」という関係の、具体的な現れです。
デバイスの柱の成熟度を段階で見る
レッスン 2 で紹介した 4 段階の成熟度を、デバイスの柱に当てはめると、次のような姿になります。
| 段階 | デバイスの柱での典型的な状態 |
|---|---|
| 伝統的 | 端末の管理は台帳での棚卸し程度で、健全性シグナルはアクセス判断に使われていない |
| 初期 | 一部の業務システムで、管理対象かどうかだけを条件に組み込み始めている |
| 高度 | OS の更新状況やディスクの暗号化などの複数シグナルを組み合わせ、条件付きアクセスに反映している |
| 最適 | 健全性シグナルの変化がリアルタイムに評価に反映され、状態が悪化した端末は即座にアクセス範囲が絞られる |
伝統的段階から初期段階への一歩は、「端末を管理しているかどうか」という比較的単純な情報を、条件付きアクセスに組み込むだけで踏み出せます。一方、高度から最適への一歩は、健全性シグナルの収集をリアルタイムに近づけ、状態変化に応じて自動的にアクセス範囲を絞り込む仕組みが必要になり、投資の規模が大きくなります。自社が今どの段階にいるかを踏まえて、次の一歩の規模を見積もることが、実務上は重要です。
管理外端末の扱い
すべての端末が組織の管理対象であるとは限りません。取引先の担当者が一時的にアクセスする場合、あるいは私物端末からの業務利用を認めている場合、組織はその端末に対して、遠隔からの設定変更やロックといった強い制御を及ぼせません。管理対象外の端末をどう扱うかは、デバイスの柱における重要な論点です。
管理外端末への対応として、よく採用されるのが次の 2 つの手法です。
仮想デスクトップ
仮想デスクトップは、業務に必要なアプリケーションやデータを、組織側が管理するサーバー上の仮想環境で動かし、利用者の端末には画面の情報だけを転送する仕組みです。実際のデータは組織側の環境にとどまり、管理外の端末にはデータそのものが渡りません。端末の健全性を完全には確認できない状況でも、データの持ち出しリスクを抑えながら業務を続けられる方法として使われます。
ブラウザ隔離
もう一つの手法が、ブラウザでの操作を隔離された環境で実行し、その結果だけを利用者の端末に届けるという方式です。Web ベースの業務システムへのアクセスに使われることが多く、端末側にファイルやデータが残らない形でアクセスを実現します。
いずれの手法も、「端末そのものを信頼できないなら、データを端末に渡さない」という発想を採っています。デバイス信頼が低い、あるいは確認できない端末に対して、一律にアクセスを拒否するのではなく、データを渡さない形でのアクセスを用意することで、業務の継続性とリスクの抑制を両立させます。
私物端末をポリシーで受け入れる設計
私物端末の業務利用を認める組織は少なくありません。全面的に禁止することは、利便性の面でも、シャドー IT を助長する面でも、現実的ではない場合が多いためです。デバイスの柱としては、私物端末を「管理対象端末と同じ水準で扱う」のではなく、「限られた条件のもとで、限られた範囲のアクセスを認める」という設計で受け入れます。
具体的には、次のような組み合わせが実務でよく採られます。
- 私物端末からは、機密度の低い業務システムへのアクセスのみを許可し、機密度の高いシステムへは仮想デスクトップ経由でのみアクセスを認める
- 私物端末に対しては、OS のバージョンや画面ロックの設定など、最低限確認できる範囲の健全性シグナルだけを条件に組み込む
- アプリ単位で業務データを管理し、端末全体ではなく、業務用アプリの領域だけを組織の管理下に置く
これらはいずれも、「端末を丸ごと管理下に置く」という発想から、「渡す情報の範囲と、確認できる範囲を、状況に応じて絞る」という発想への転換です。管理外端末への対応と同様に、デバイス信頼の水準に応じてアクセスできる範囲を段階的に変える設計が、私物端末の扱いにおいても中心的な考え方になります。
私物端末の扱いを、デバイス信頼の水準ごとに整理すると、次のようなイメージになります。
| デバイス信頼の水準 | アクセスできる範囲の例 |
|---|---|
| 確認できる健全性シグナルが乏しい私物端末 | 社内掲示板など、機密度の低い情報の閲覧のみ |
| 最低限の健全性シグナル(画面ロック設定など)を満たす私物端末 | 一般業務のメールやスケジュールの閲覧・入力 |
| 業務用アプリの領域だけを組織が管理する私物端末 | 特定の業務アプリを通じた、限定的なデータの取り扱い |
| 組織が管理する端末 | 機密度の高いシステムを含む、通常業務全般 |
この整理からわかるとおり、私物端末を「全面的に禁止するか、全面的に許可するか」という二択で捉える必要はありません。デバイス信頼の水準に応じて、アクセスできる範囲を段階的に広げていく設計こそが、デバイスの柱が目指す姿です。
⚠️ 注意 私物端末の扱いを「禁止か許可か」の二択で議論すると、現場の実態と噛み合わなくなりがちです。デバイスの柱の成熟度が上がるほど、「どの端末から、どこまでのアクセスを認めるか」という段階的な設計が可能になります。この発想は、レッスン 6 で扱うデータ分類とも密接に関わってきます。
デバイスの柱でよくあるつまずき
デバイスの柱に着手する組織が、共通してつまずきやすい点を整理しておきます。
資産管理台帳と、実際に稼働している端末が一致していない
デバイスポスチャを評価する前提として、「組織が把握している端末の一覧」と「実際にアクセスしてきている端末」が一致している必要があります。台帳の更新が追いついておらず、退職者に貸与していた端末が回収されないまま残っていたり、逆に新しく配布した端末が台帳に反映されていなかったりすると、健全性シグナルをいくら精緻に設計しても、判断の土台が崩れてしまいます。デバイスの柱を育てる作業は、地味な資産棚卸しの精度を上げる作業と、切り離せません。
健全性シグナルを集めることが目的化する
健全性シグナルを収集する仕組みを導入したこと自体に満足してしまい、そのシグナルが実際のアクセス判断に反映されていない、という状態に陥ることがあります。シグナルを集めるだけでは、成熟度モデル上は伝統的段階のままです。集めた情報を条件付きアクセスのポリシーに結びつけ、実際にアクセス範囲を左右する形にして初めて、次の段階に進んだと言えます。
管理外端末への対応を後回しにしてしまう
組織が管理する端末への対策を優先するあまり、私物端末や取引先の端末への対応が後回しになりがちです。しかし、管理外端末は、健全性を直接確認できない分だけ、アタックサーフェスとしてのリスクが高い領域です。仮想デスクトップやブラウザ隔離といった代替手段を、優先順位の高い課題として位置づける必要があります。
アイデンティティの柱との連携が遅れる
デバイスの柱を独立したプロジェクトとして進めてしまい、レッスン 3 で見た条件付きアクセスのポリシーへの反映が後回しになるケースも見られます。健全性シグナルを集める仕組みだけを整えても、それがアクセス判断に使われていなければ、成熟度モデル上の前進にはつながりません。デバイスの柱の計画は、アイデンティティの柱の担当者と、最初から一体で進める方が、手戻りが少なくなります。
まとめ
このレッスンでは、以下のことを学びました。
- デバイスの柱は、利用者の身元とは別に、利用者が使っている端末の状態を確認する役割を担う
- デバイスポスチャは、端末の健全性を継続的に把握する考え方で、一度きりの検査ではない
- 健全性シグナルには、OS の更新状況、ディスクの暗号化、監視ソフトの稼働、管理対象かどうかがある
- デバイス信頼は、条件付きアクセスのポリシーと結びつくことで、アクセス判断の精度を高める
- 管理外端末には、仮想デスクトップやブラウザ隔離という、データを端末に渡さない対応が有効である
- 私物端末は、端末全体を管理下に置くのではなく、限られた条件のもとで限られた範囲のアクセスを認める設計で受け入れる
次のレッスンでは、アイデンティティとデバイスの 2 つの柱を土台に、ネットワークの柱を扱います。VPN からの出口をどう設計するか、本コースの中核的な論点の一つに踏み込みます。アイデンティティで「誰か」を、デバイスで「何を使っているか」を確認できるようになって初めて、ネットワークの柱で「どこに、どこまでの通信を許すか」という設計が意味を持ち始めます。
確認クイズ
このレッスンの理解度をチェックしましょう。