ゼロトラストの仕組み — ログイン後も「何をしてよいか」を確かめる
ログイン後も、対象ごとの権限を確認
- 身近な例から役割をつかむ
- 確認できる結果と成立条件を区別する
- 次の学習や導入判断につなげる
ひよこ 
ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 会社の資料で考えてみよう
営業担当が売上資料を読む場面を考えます。「社内からアクセスしているので、全資料を許可」では、人事資料へのアクセスまで広げてしまいます。ゼロトラストでは、守る対象と、その対象に必要な権限を決めます。
| 練習用の場面 | 判断の例 | 理由 |
|---|---|---|
| 営業担当が担当の売上資料を読む | 条件を満たせば許可 | 仕事に必要な権限がある |
| 同じ人が人事資料を読む | 拒否 | 社内にいても権限がない |
| 許可対象だが端末に異常がある | 制限や追加確認 | 端末状態も判断材料になる |
これは考え方を学ぶための例です。会社ごとの情報分類、業務、端末管理に沿って方針を設計します。位置だけで許可・拒否を決める表ではありません。
本人確認と権限確認を分ける
認証は「誰か」を確かめること、認可は「何をしてよいか」を決めることです。正しくログインした人でも、担当外の資料への権限があるとは限りません。
NIST SP 800-207は、ネットワークの場所だけで暗黙の信頼を与えず、リソースへのアクセスを個別に制御する考え方を示しています。アクセス許可はセッション単位などで評価し、その後も状態を監視します。全HTTPリクエストごとに人がパスワードを入力する、という定義ではありません。
「3原則」は誰の整理か
Microsoftが示す整理は次の3つです。
- 明示的に検証する：本人、端末、対象などの情報を判断に使う。
- 最小限の権限にする：必要な操作と期間に絞る。
- 侵害を想定する：侵入後の拡大を抑え、検知・対応を考える。
NISTの文書は、通信の保護、リソースごとの許可、動的な方針、状態の監視などを7つの基本的な考え方として示しています。上の3つをそのままNISTの原則として引用しないようにしましょう。
判断する役割と、実際に止める役割
| 論理的な役割 | すること |
|---|---|
| Policy Engine（PE） | 方針と状態に基づき、許可・拒否を決める |
| Policy Administrator（PA） | 判断に従い、接続の開始・終了などを設定する |
| Policy Enforcement Point（PEP） | 利用者と対象の間でアクセスを通す・止める |
端末の状態、ID管理、ログなどの情報が判断を支えます。これらは役割の区分で、必ず3製品を購入する構成図ではありません。接続後の異常にも対応できるよう、再評価と終了の仕組みを用意します。
最初に取り組むなら、重要な資料を1つ選ぶ
守る対象と利用者の一覧を作り、読む・書く・削除する権限を確認するところから始めます。その後、本人確認や端末の条件、ログの確認、権限の失効、例外時の手続きを整えます。適用前に、正規の利用者を不必要に締め出さないか、障害時にどうするかを検証します。
ゼロトラストは攻撃をゼロにする保証でも、VPNを必ず廃止する指示でもありません。ネットワークの防御とアクセス制御は組み合わせられます。「製品を入れたから完了」ではなく、業務と状態に合わせて方針を見直す運用も含めて考えましょう。
次はRBACの仕組みで、役割と権限の結び付けを学べます。
参考資料
- NIST SP 800-207 — 定義と公式文書
- NIST文書の本文 — 7つの基本的な考え方とPE・PA・PEP
- Microsoft Zero Trust — 3原則の整理