レッスン3：柱①アイデンティティ——「毎回確かめる」をポリシーで書く

このレッスンで学ぶこと

アイデンティティの柱が、5 つの柱の中でどのような位置づけにあるかを理解する
条件付きアクセスというポリシーの組み立て方を説明できる
アクセス判断に使われる代表的なシグナルの種類を整理できる
リスクベース認証の考え方を理解する
RBAC と ABAC の違いと、使い分けの発想を持つ
特権アクセス管理と Just-In-Time 権限昇格、IDaaS の位置づけを把握する

前回のレッスンでは、CISA ゼロトラスト成熟度モデルを使って、自社の現在地を柱ごとに測る方法を学びました。今回からは、5 つの柱を一つずつ、設計の中身まで踏み込んで見ていきます。最初に取り上げるのは、アイデンティティの柱です。多くの組織が、ゼロトラスト移行の最初の一歩としてこの柱に着手します。理由は単純で、「誰が」を確認できなければ、ほかのどの柱の判断も土台を欠くからです。

なぜアイデンティティの柱から始まるのか

レッスン 1 で確認した NIST SP 800-207 の原則を思い出してください。4 番目の原則は「リソースへのアクセスは動的なポリシーで決定する」というものでした。このポリシーが最初に必要とする情報は、「アクセスしようとしているのは誰か」という、利用者の識別情報です。

アイデンティティの柱が整っていない状態では、デバイスの柱がどれだけ進んでいても、「この端末を使っているのが誰なのか」を確定できません。ネットワークの柱を見直そうとしても、「誰にどこまでの通信を許すか」を定義する起点がありません。アイデンティティは、ほかの柱の判断材料を組み立てるための土台にあたります。多くの組織がこの柱から着手するのは、投資対効果が見えやすいことに加えて、こうした構造上の理由があるからです。

💡 ポイント 「まずアイデンティティから」という順序は、本コースが推奨する唯一の正解ではありません。業務の実態によっては、デバイスやネットワークの課題の方が緊急度が高い組織もあります。ただし、多くの組織にとってアイデンティティが土台になりやすいという傾向は、レッスン 8 の移行ロードマップを考えるうえでも押さえておく価値があります。

条件付きアクセス——「毎回確かめる」をポリシーの形にする

レッスン 1 で扱った Never Trust, Always Verify という標語を、実際のアクセス制御の仕組みに落とし込んだものが、条件付きアクセスというポリシーの考え方です。

条件付きアクセスとは、「特定の条件が満たされたときに、特定の対応を取る」という形で書かれるアクセスポリシーです。単純化すると、次のような構造を持ちます。

条件：誰が、どのような状態で、何にアクセスしようとしているか
対応：アクセスを許可する、追加の確認を求める、拒否する、のいずれか

例えば、「社外からアクセスしようとしている」という条件に対して、「追加の確認を求める」という対応を組み合わせる。あるいは、「管理者権限のシステムに、管理対象外の端末からアクセスしようとしている」という条件に対して、「アクセスを拒否する」という対応を組み合わせる。このように、条件と対応の組み合わせを積み重ねていくのが、条件付きアクセスの基本的な設計作業です。

従来の認証は、「正しいパスワードと多要素認証を通過すれば、以後はアクセスを許可する」という一度限りの関所でした。条件付きアクセスは、この関所を、状況に応じて毎回姿を変える仕組みに置き換えます。同じ利用者であっても、いつ、どこから、どんな端末でアクセスするかによって、求められる確認の強さが変わるのです。

判断に使うシグナル

条件付きアクセスの「条件」を組み立てるためには、判断材料となる情報、つまりシグナルが必要です。代表的なシグナルには、次のようなものがあります。

利用者のリスク：漏洩した認証情報の一覧に一致していないか、普段と異なる振る舞いが検知されていないかなど、利用者アカウントそのものに関するリスク評価
サインインのリスク：今回のログイン試行そのものが、普段と異なる特徴を持っていないかという評価。同じ利用者でも、ログインのたびに変化しうる情報です
場所：アクセス元の地理的な位置や、組織が管理するネットワークからのアクセスかどうか
端末の状態：アクセスに使われている端末が、組織の管理対象であるか、健全な状態にあるかという情報。この項目は、レッスン 4 で扱うデバイスの柱と直接つながります

これらのシグナルは、単独で使われることもありますが、複数を組み合わせて評価されるのが実務での標準的な設計です。「場所は普段どおりだが、サインインのリスクが高い」という組み合わせと、「場所が普段と異なるが、端末の状態は健全」という組み合わせでは、取るべき対応が変わってきます。

flowchart LR
  S1[利用者のリスク] --> J[判断]
  S2[サインインのリスク] --> J
  S3[場所] --> J
  S4[端末の状態] --> J
  J --> A1[許可]
  J --> A2[追加確認]
  J --> A3[拒否]

📝 補足 シグナルを組み合わせて判断する仕組みそのものは、多要素認証や暗号化と並ぶ、情報セキュリティ関連の入門コースの範囲外にある発想です。多要素認証が「本人確認の手段」であるのに対し、条件付きアクセスは「その手段をいつ、どの強さで要求するか」を決める、一段上の設計にあたります。

設計例で見る条件と対応の組み合わせ

条件付きアクセスの設計は、抽象的な話に聞こえるかもしれません。具体的な組み合わせの例を見ると、輪郭がつかみやすくなります。

条件の例	対応の例
管理対象外の端末から、管理系システムにアクセスしようとしている	アクセスを拒否する
普段と異なる国からのサインインで、利用者のリスクも高いと評価されている	アクセスを拒否し、管理者へ通知する
社外からのアクセスだが、端末は管理対象で健全な状態にある	追加の確認を求めたうえで許可する
社内ネットワークからのアクセスで、利用者・サインインともにリスクが低い	通常の認証で許可する

この一覧からわかるのは、「社外からのアクセスだから一律に危険」という単純な発想ではなく、複数のシグナルの組み合わせによって対応が変わるという点です。同じ「社外からのアクセス」であっても、端末の状態が健全であれば追加確認で済み、利用者のリスクも高ければ拒否に踏み込む。この粒度の設計が、条件付きアクセスの実務です。

リスクベース認証

条件付きアクセスのシグナルを、認証の強さそのものに反映させる考え方が、リスクベース認証です。すべてのアクセスに一律の強さの認証を求めるのではなく、評価されたリスクの高さに応じて、認証の要求水準を上下させます。

リスクが低いと判断されたアクセス——普段と同じ端末、普段と同じ場所、利用者のリスクも低い——であれば、通常の認証で通します。一方、リスクが高いと判断されたアクセス——見慣れない場所から、初めて使う端末で、深夜にアクセスしている、といった組み合わせ——であれば、追加の確認を求めるか、そもそもアクセスを拒否します。

この発想は、NIST SP 800-207 の 4 番目の原則が示す「動的なポリシー」を、認証の場面で具体的に実装したものです。すべてのアクセスに常に最も厳しい認証を課すと、正当な利用者の利便性を過度に損ないます。逆に、すべてのアクセスを一律に緩い認証で通すと、アイデンティティの柱としての意味がなくなります。リスクベース認証は、この両極のあいだで、状況に応じたバランスを取るための仕組みです。

⚠️ 注意 リスクベース認証は「リスクが高そうな人を締め出す」ための仕組みではありません。正当な利用者であっても、普段と違う状況でアクセスすれば、追加の確認を求められることがあります。これは不便に感じられるかもしれませんが、同じ状況が悪意ある第三者による不正アクセスだった場合には、被害を防ぐ最後の砦になります。

RBAC と ABAC の使い分け

アクセスを許可するかどうかを判断したあと、次に問われるのが「どこまでの操作を許可するか」という認可の設計です。ここで登場するのが、RBAC と ABAC という 2 つの考え方です。

RBAC——役割にもとづく権限付与

RBAC は、利用者に「役割」を割り当て、その役割に応じた権限をまとめて付与する方式です。「経理担当者」という役割には、会計システムの参照・入力権限をまとめて割り当てる、「システム管理者」という役割には、管理系システムへの操作権限をまとめて割り当てる、といった具合です。役割ごとに権限をまとめておけるため、設計と運用がシンプルになりやすく、多くの組織で最初に採用される認可方式です。

ABAC——属性にもとづく権限付与

ABAC は、利用者の属性、リソースの属性、環境の属性など、複数の情報を組み合わせて、そのつどアクセス可否を判断する方式です。「経理部に所属し、かつ管理対象端末を使用し、かつ勤務時間内である」利用者にだけ、特定の会計データへのアクセスを許可する、といった、複数条件を動的に組み合わせた設計が可能になります。RBAC が「役割ごとにあらかじめ決めておく」静的な設計であるのに対し、ABAC は「そのつど条件を評価する」動的な設計です。

使い分けの発想

観点	RBAC	ABAC
設計のしやすさ	役割の数が少なければ容易	条件が複雑になるほど設計に手間がかかる
柔軟性	役割の粒度に縛られる	状況に応じた細かい制御が可能
向いている場面	権限の種類が比較的固定的な業務	高リスクなデータやシステムへの、状況に応じたアクセス制御

多くの組織では、まず RBAC で全体の権限構造を整理し、特にリスクの高いデータやシステムに限って ABAC を組み合わせる、という段階的な採用が現実的です。すべてを ABAC で設計しようとすると、条件の組み合わせが膨大になり、かえって運用が破綻します。NIST SP 800-207 が示す「動的なポリシー」という理想と、実際に運用できる複雑さのバランスを取ることが、この節の核心です。

特権アクセス管理と Just-In-Time 権限昇格

一般利用者のアクセス管理に加えて、アイデンティティの柱でとりわけ重要なのが、管理者権限を持つアカウントの扱いです。この領域を扱う仕組みが、特権アクセス管理（PAM）です。

特権アクセス管理は、システム管理者やデータベース管理者など、強い権限を持つアカウントを、一般アカウントとは別の水準で保護・監視する仕組みです。強い権限を持つアカウントが侵害されると、被害の範囲が一気に拡大するため、通常よりも厳格な認証、操作の記録、利用状況の監視が求められます。

特権アクセス管理の実装でよく組み合わされるのが、Just-In-Time 権限昇格という発想です。これは、管理者権限を常時付与しておくのではなく、必要な作業のときだけ、必要な時間だけ、権限を一時的に昇格させる仕組みです。作業が終われば、権限は自動的に元の水準に戻ります。

常時、強い権限を持ち続けるアカウントは、それ自体が大きな標的になります。攻撃者に一度でも乗っ取られれば、いつでも強い権限を行使できてしまうからです。Just-In-Time 権限昇格は、「権限を持っている時間」そのものを最小化することで、この標的としての魅力を下げます。最小権限の原則を、時間軸に沿って徹底する発想だと捉えると理解しやすくなります。

💡 ポイント 特権アクセス管理と Just-In-Time 権限昇格は、レッスン 2 で扱った成熟度モデルにおいて、アイデンティティの柱が初期段階から高度段階に進むときの、代表的な取り組みの一つです。「常時付与」から「必要なときだけ昇格」への転換は、地味に見えて、アタックサーフェスを大きく縮小する効果があります。

IDaaS の位置づけ

ここまで説明してきた条件付きアクセス、リスクベース認証、RBAC と ABAC、特権アクセス管理といった機能は、自社ですべてを一から構築することもできますが、多くの組織では、これらの機能をクラウド上のサービスとして利用します。この形態を、IDaaS と呼びます。

IDaaS は、アイデンティティ管理の機能をクラウドサービスとして提供する仕組みです。レッスン 1 で説明したポリシーエンジンとポリシー管理者の役割の多くを、IDaaS が肩代わりすることになります。自社で個別に開発・運用するよりも、標準的な機能を短期間で導入できる利点がある一方、自社の業務に合わせた細かい条件設計をどこまで実現できるかは、選択するサービスの機能に左右されます。

本コースでは、特定の製品やサービスの比較には踏み込みません。製品選定は情シス関連の入門コースの範囲であり、本コースが扱うのは、IDaaS という仕組みが、アイデンティティの柱のどの部分を担うのかという位置づけです。IDaaS を導入すること自体はゴールではなく、その上でどのような条件付きアクセスのポリシーを設計するかが、実際の成熟度を左右します。

アイデンティティの柱でよくあるつまずき

現場でアイデンティティの柱に着手する組織が、共通してつまずきやすい点を整理しておきます。

ポリシーを厳しくしすぎて業務が止まる

条件付きアクセスを導入した直後に、最も厳しい条件をいきなり全社へ適用してしまうと、正当な利用者まで締め出してしまう事態が起きます。まずは記録だけを行い実際には遮断しないモードでポリシーを試験運用し、想定外の遮断が起きないかを確認してから、段階的に強制力を持たせるのが安全な進め方です。

例外だらけになり形骸化する

逆に、業務からの反発を避けようとして例外設定を積み重ねていくと、ポリシーは徐々に骨抜きになります。「この部署だけは対象外」「このシステムだけは古い認証方式のまま」という例外が積み重なると、成熟度モデル上は進んでいるように見えても、実態としてのアタックサーフェスは縮小していません。例外は一覧化し、定期的に見直す仕組みとセットで運用する必要があります。

判断を一つのシグナルに頼りすぎる

「場所」だけ、あるいは「多要素認証の有無」だけでアクセスを判断してしまうと、条件付きアクセスの効果は限定的になります。複数のシグナルを組み合わせてこそ、リスクベース認証の精度が上がります。この点は、次のレッスンで扱うデバイスの柱の成熟度が上がるほど、判断材料として活きてきます。

アイデンティティの柱の成熟度を段階で見る

レッスン 2 で紹介した 4 段階の成熟度を、アイデンティティの柱に当てはめると、次のような姿になります。

段階	アイデンティティの柱での典型的な状態
伝統的	パスワードと多要素認証のみで、条件付きアクセスの仕組みが存在しない
初期	一部の重要な業務システムに、場所や利用者のリスクなど、単一のシグナルで条件付きアクセスを導入している
高度	複数のシグナルを組み合わせたリスクベース認証が、主要な業務システムに展開されている
最適	RBAC と ABAC を使い分け、特権アクセス管理と Just-In-Time 権限昇格が日常運用に組み込まれている

多くの組織にとって、伝統的段階から初期段階への一歩は、既存の多要素認証の仕組みに、条件付きアクセスの機能を一つ追加するだけで踏み出せます。一方、高度から最適への一歩は、RBAC と ABAC の使い分けや特権アクセス管理の整備まで含むため、組織的な合意形成に時間がかかりやすい段階です。

まとめ

このレッスンでは、以下のことを学びました。

アイデンティティの柱は、ほかの柱の判断材料を組み立てるための土台にあたる
条件付きアクセスは、「条件」と「対応」の組み合わせで、Never Trust, Always Verify をポリシーの形にする
判断に使うシグナルには、利用者のリスク、サインインのリスク、場所、端末の状態がある
リスクベース認証は、評価されたリスクの高さに応じて、認証の要求水準を動的に変える
RBAC は役割にもとづく静的な権限付与、ABAC は属性にもとづく動的な権限付与で、多くの組織は RBAC を土台に、高リスク領域だけ ABAC を組み合わせる
特権アクセス管理と Just-In-Time 権限昇格は、強い権限を持つ時間そのものを最小化する
IDaaS は、アイデンティティ管理の機能をクラウドサービスとして提供する仕組みで、その上でのポリシー設計が実際の成熟度を左右する

次のレッスンでは、アイデンティティの柱と密接につながるデバイスの柱を取り上げます。「この端末を使っているのは誰か」だけでなく、「この端末は、信頼できる状態にあるか」をアクセス判断に組み込む方法を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。