情シス部門のゼロトラスト導入に向けて#6　認証認可について考えてみよう（後編）

最近バズワードになっている「ゼロトラスト」について「会社の指示で情シス部門がゼロトラストを導入しなければならない」、「クラウドにSSOを導入するのと何が違うのか」といった相談がありました。ゼロトラストについてうまく説明できないとしたら、予算を作ることも導入に踏み切ることも難しいと思います。こうした疑問についてNISTやIPAのゼロトラスト・アーキテクチャからラックの考えるゼロトラストについてひもといて行きたいと思います。

前編では「全ての資産の認証と認可は動的に行われ、アクセスが許可される前に厳格に実施する」というゼロトラストの前提について、NISTの考え方と現状とのギャップについて解説しました。

後編はZTAを実装するために必要なICAM構成について、ラックの考えるゼロトラストを伝えます。

ZTAを実装するために必要なICAM構成について

CISAは、『CONTINUOUS DIAGNOSTICS AND MITIGATION PROGRAM』の中で"強力なアイデンティティ管理と成熟したICAM能力がNPE（Non-Protected Entities：非保護エンティティ）にない場合、ゼロトラストは達成できない"と、述べられています。

※ CONTINUOUS DIAGNOSTICS AND MITIGATION PROGRAM

NPE（Non-Protected Entities：非保護エンティティ）

組織、ハードウェア・デバイス、ソフトウェア・アプリケーション、および情報アーティファクトなど、デジタルアイデンティティを持つすべてのエンティティが含まれます。

よって、ZTAを実装するために必要なICAMには以下が含まれます。

• PE（Protected Entities：保護されたエンティティ）およびNPE（Non-Protected Entities：非保護エンティティ）
  アクセスを提供する前にすべてのユーザを認証します。アイデンティティを管理し、安全な多要素認証（MFA）による資格情報を提供することは、アクセスを要求する人を判断する最初のステップです。
• エンドポイント
  ユーザーを認証することに加えて、ゼロトラストはワークステーション、モバイル・デバイス、またはIoTデバイスなどのエンドポイントの認証と承認を要求します。
• データ、資産、アプリケーション、およびサービス
  アクセスポリシーの定義と実装は、ゼロトラストの継続的評価の側面を実装するために必要です。

さらに、ゼロトラスト成熟度モデルによって成熟度を高める必要があります。

ゼロトラスト成熟度モデル

CISAが2021年6月にゼロトラスト成熟度モデルのドラフト版を公開しました。ゼロトラスト成熟度モデルは、5つの異なる柱に沿って実装度合いを表しており、最適化に向けて時間をかけて少しずつ進歩させることができます。

5つの柱とは、図で示すように、アイデンティティ、デバイス、ネットワーク、アプリケーション・ワークロード、データです。それぞれの柱には、「可視性と分析」、「自動化とオーケストレーション」、「ガバナンス」に関する一般的な内容も含まれています。この成熟度モデルは、ゼロトラストへの移行をサポートするための道しるべとなるものです。

アイデンティティの柱とアイデンティティ管理について

IDライフサイクルのマネジメント

IDライフサイクル管理は、データを保護するための中核となるIDサービスです。人間のアイデンティティと同様に、デジタルアイデンティティも、作成から引退まで同様のプロセスをたどります。従業員は、審査/身元証明を完了し、複数のシステムでアカウントを作成し、昇進し、最終的に組織を離れます。

IDライフサイクル管理には、エンタープライズID、資格情報、アクセス管理（ICAM）システムでのデジタルIDの作成、IDプルーフィング/審査、プロビジョニング、メンテナンス、集約および活動停止のアクティビティが含まれます。

連邦政府のICAMコミュニティでは、IDに関連するすべてのものをPIVと同義語で呼び、PIVカードを使用してIDプロセスを実行する方法と比較するのが一般的です。デジタルIDとPIVカードの主な違いは、組織内のユーザアカウント、ペルソナ、属性、資格、および資格情報を一意に表現したマスタ・ユーザ・レコードで形式化されています。1つのデジタルIDは1つのPIVカードにリンクされていますが、その1つのIDには、PIVカードが使用されていないアプリマスター・ユーザー・レコードするために使用される複数のアカウント、属性、資格、および潜在的に他の非PIV認証情報（ユーザ名とパスワード、ワンタイムPINアプリなど）が含まれる場合があります。

IDライフサイクル・プロセス

ステージ1 参加者

• 1.作成
  新しいユーザのアイデンティティを作成し、そのアイデンティティを組織のマスタ・ユーザ・レコードに関連付けるプロセスです。ここでは、ユーザが初めて組織に参加する際に必要なアクションが行われます。
• 2.身元証明/審査
  新しいユーザが組織に参加する際に、その身元を確認し、信頼性を確保するためのプロセスです。
• 3.プロビジョニング
  ユーザのアカウントや権限を適切に作成管理し、必要なリソースへのアクセスを提供するプロセスです。このプロセスは、新しく組織に加わった参加者がシステムやサービスを利用できるようにするためのステップです。

ステージ2 異動者

• 1.メンテナンス
  マスタ・ユーザ・レコードに関連する属性や権限を正確かつ最新の状態に維持するプロセスです。このプロセスは、ユーザの役職や職務の変更に伴って随時行われます。
• 2.ID（アイデンティティ）の集約
  異なるデジタルIDを見つけてマスタ・ユーザ・レコードに接続するプロセスです。これにより、個人やエンティティに関するすべての情報が1つの統一されたレコードに統合されます。

ステージ3 退出者

• 1.非アクティブ化
  ユーザが組織を離れる際にそのアカウントを無効にし、システムへのアクセスを停止するプロセスです。このプロセスを適切に実施することで、セキュリティリスクを最小化し、データの保護とコンプライアンスの維持を確保します。

クラウド・アイデンティティ

ステップ1：サポートを得る

• 1.ユーザーストーリーを書く
  ユーザーストーリーは、エンドユーザーの観点から目標、機能について書かれた簡単な説明です。
  【ユーザのタイプ】として、私は【何らかの理由】のために【何らかの目標、機能】を望んでいる。
  例）営業として、私は客先でのプレゼンのためにリモートデスクトップを望んでいる。
  ・ビジネスニーズを満たす機能または要件の説明、および概要。
  ・受け入れ基準、つまりユーザーストーリーを「完了」と呼ぶために必要なアクションを用意します。
• 2.ビジネスケースを書く
  資金調達の検討を含むビジネスケースの草案を作成する必要があります。ビジネスケースでは、例として、次のような利点と価値を明確にする必要があります。
  ・ゼロトラストをサポートするICAM機能。
  ・ビジネスプロセスを強化するIDaaSへの移行。
  ・ユーザーエクスペリエンスの向上、ダウンストリームのコスト削減、リスク管理と災害復旧を改善。
   ビジネスケースの重要な要素として利害関係の分析を行います。

ゼロトラストの柱	IDaaSイネーブラー
アイデンティティ	IDaaSは、複数のフィッシング耐性のある認証オプションをサポートする単一のプラットフォームにSSO、MFA、およびディレクトリサービスを組み込んでいます。これにより、アプリケーション プログラミング インターフェースでIDaaS IDストア情報を迅速にクエリできるようになり、セキュリティの問い合わせを集中管理できるようになります。クラウドサービスは最新のプラットフォーム上で動作し、オンプレミスのIDプロバイダーよりも迅速に新しいプロトコルと機能を統合できます。アイデンティティ インフラストラクチャの維持よりもアイデンティティ サービスの提供に重点を置けます。
デバイス	IDaaSはポリシー適用ポイントとして機能し、デバイスの種類、オペレーティングシステムのバージョン、場所などのデバイスの識別と正常性属性を活用して、アクセスと認可の決定を支援します。
ネットワーク	SDN、CASB、およびその他のゼロトラスト ネットワーク ソリューションは、アクセスおよび認可の決定の一部としてID属性を提供するためにIDプロバイダーと統合する必要があります。これによりクラウドソリューションとより効率的に統合できます。またIDaaSはリスク指標に基づいてリアルタイムのセッション変更を検出する機能を備えています。
アプリケーション	IDaaSは、アクセスを一元化した集中型のポリシー実行ポイントとして機能します。脅威防御データソースと統合し、人工知能と機械学習を活用して継続的な承認決定を適用し、動的な強制ポイントを作成します。
データ	IDaaSは、アクセス デシジョン ポイントの一部としてデータタグを使用する高度なアクセスポリシーをサポートします。

ステップ2：計画を文章化する

• 1.戦略的目標とアプローチの概要を示すCloud Identity戦略の草案を作成します。
• 2.成果を定量的評価が可能な指標を含めます。
• 3.戦略の達成に役立つ特定のガバナンス要素を把握するポリシーを作成します。

クラウド・アイデンティティ戦略と目標

Cloud Identity戦略は、組織が協調して機能するのに役立ちます。戦略と目標を組み合わせることが重要です。例としては、機能の拡散を防ぐためのIDサービス（戦略）の統合（目標）があります。

大規模な組織では、最新化、セキュリティ、アイデンティティベースのさまざまな戦略を採用している場合もありますが、小規模な組織ではこれらの要素を1つのドキュメントに含めている場合があります。

ICAMの実践領域とサービスフレームワークは、図に示すように5つのコアサービスとサブサービスがあります。これらを使用して、ICAMサービスを特定し、計画をFICAMアーキテクチャに合わせます。

コアサービス	ビジネス要件	クラウドオプション
アイデンティティ管理	すべてのユーザIDを確立して管理します。	多くのIDaaSには、オンプレミスのディレクトリと同期するディレクトリサービスが付属しています。IDaaSには仮想ディレクトリ機能も備わっている場合があります。
資格情報の管理	オープンスタンダードなICAMソリューションを構築することで、全組織の相互運用性と効率性を促進します。	複数種類のフィッシング耐性を持つ認証システムをサポートするIDaaSを活用します。パスワードレスもしくはMFAを採用します。
アクセス管理	リソースにアクセスするための効率的かつ安全な方法を提供するクラウド対応サービスを採用します。	主な機能としてSSOがあります。
ガバナンス	データを戦略的資産として使用して、アダプティブかつリスクに基づいた意思決定を行うことで、ユーザの行動とイベントを監視し、対応します。	IDaaSがユーザ行動分析をサポートするためにログをエクスポートできることを確認してください。テクニカル アイデンティティ ガバナンスの一環として、ロールマイニング、自動プロビジョニング、プロビジョニング解除、アカウント検出のためのアクセス認証と分析を実行します。
フェデレーション	ソリューションを活用して、他の組織やミッションパートナーが作成したIDと認証のアサーションを効率的に受け入れます。	OAuthなどを用いたSSOを介してアクセスを実装します。ガバナンスと技術要件を文章化した法的合意は、フェデレーションの重要なポイントです。

Cloud Identity戦略を定義する際に考慮すべき5つの目標

• 1.機能の重複とスプロールの防止
  目的：アイデンティティおよびアクセス管理（ICAM）サービスの重複や無駄を防ぎ、効率を最大化します。
  IDとさまざまなアプリケーションが遍在しているため、組織内で重複するICAMサービスがまん延する可能性があります。まず、権威のあるエンタープライズICAMサービスを特定する必要があります。次にICAM機能を分析することで、スプロールと重複の防止を行います。
• 2.サービスを一元化してエンタープライズ機能を構築
  目的：組織内で複数のアイデンティティ・ディレクトリを管理し、統一されたデジタルアイデンティティを提供します。
  組織は複数のIDディレクトリを管理する場合があります。ユーザは多数のペルソナを持てますが、組織内のマスターユーザ レコードに関連付けられた1つのデジタルIDを持つ必要があります。デジタルIDをエンタープライズレベルで管理します。権威あるアイデンティティソースは、ディレクトリ サービスにフィードされる正確な情報リポジトリです。これにはユーザが編集できないデータソースが含まれる場合があります。例えば、自分の電話番号を更新できますが、クリアランスステータスは更新できません。
• 3.PE（人物）とNPE（非人物）エンティティ
  目的：すべてのアイデンティティ（人物および非人物）を戦略に組み込み、それぞれに適した管理方法を適用します。
  戦略にすべてのアイデンティティを組み込みます。PE（人物）だけでなくNPE（非人物）には、人間の作業者に代わって特定の業務プロセスやタスクを実行するソフトウェア、RPAによるボット、AIアシスタントといったデジタルワーカー、サーバーやネットワーク機器、その他システムやサービスに割り当てられるマシンIDなどがあります。
• 4.ネットワークアクセス
  目的：デバイスのトラフィックをIDaaSに誘導し、認証と認可の決定を適用することにより、セキュアなネットワークアクセスを実現します。
  オンプレミスネットワーク認証とIDaaSの主な違いは、認証と認可の決定をするために、デバイストラフィックをIDaaSに誘導および監視する必要があることです。誘導はWebサイトにアクセスするためのデバイスの構成によって異なります。通常これらは、CASB、SASE、またはフォワードプロキシやリバースプロキシを介した接続など、トラステッドなインターネット接続による承認されたクラウドアクセス方法です。
• 5.自動化
  目的：拡大するインフラストラクチャのスケールと規模に対応するために、自動化を実装します。
  インフラのスケールとサイズがますます増大する中で、自動化が有利に働く場所とタイミングで導入します。

ステップ3：アーキテクチャに関する考慮事項

IDaaSを導入する際に組織が直面する課題を解決するための具体的な指針です。これらの考慮事項は、FICAM（Federal Identity, Credential, and Access Management）サービスフレームワークに沿ったものであり、プログラムインターフェイスとオープンスタンダードなOAuthなどによる承認の自動化をカバーする、クラウドベースのツールを活用することが挙げられます。

• 1.アイデンティティの自動化
  目的：手動プロセスを自動化し、効率を向上させること。
  IDaaSの特徴の1つは、手動プロセスを自動化できることです。例えば、14日間または30日間使用されなかったユーザのアカウントを自動的に停止できます。API統合を活用して、他のITツールとのライフサイクル管理プロセスを自動化します。例えば、IDaaSをITサービス管理ツールと統合し、権限の追跡と監査を実施できます。IDプロセスの自動化は、成熟したゼロトラスト機能です。
• 2.正確なディレクトリ情報
  目的：クラウドへの移行前に正確なソースディレクトリ情報を確保すること。
  IDaaSプロジェクトを開始する前に、ソースディレクトリ情報が正しいことを確認してください。IDaaSはオンプレミスのディレクトリをクラウドのディレクトリにレプリケートし、双方向同期または一方向同期をサポートしています。ディレクトリのクリーニングは、レプリケーションの前に実施してください。
• 3.仮想ディレクトリ
  目的：特定のアプリケーションに応じたユニークなペルソナを作成すること。
  クラウドアプリケーションへのアクセスは全て同じではありません。仮想ディレクトリを使用して、既存のディレクトリ情報に基づいて特定のアプリケーションにユニークなペルソナを作成することを検討してください。仮想ディレクトリは、さまざまなソースからのIDデータを集約し、ユニークなペルソナを作成できます。IDaaSは仮想ディレクトリ機能をサポートし、マスタ・ユーザ・レコードとして機能します。
• 4.エンタイトルメント管理
  目的：ロールベースのエンタイトルメント管理を実施し、アクセス権限を効率的に管理すること。
  ほとんどのクラウドアプリケーションとプラットフォームは、ロールベースの権限管理を実装しています。権限管理は、個人ではなくグループ内のユーザに基づいて行われます。グループは、管理者、請負業者、コントリビューターまたはリーダーなどの固有の役割で構成されます。グループ内のすべてのユーザは同じ権限を継承します。権限管理は、そのグループからユーザを削除するのと同じくらい簡単です。
• 5.非人物エンティティ（NPE）のアイデンティティ管理
  目的：サービスアカウント、RPAボット、スクリプトなど、さまざまな非人物エンティティのアイデンティティを適切に管理すること。
  NPE、マシンID、またはデジタルワーカーのタイプごとに、異なる構成またはタイプの管理が必要な場合があります。さまざまなNPE IDのカタログを作成することから始めます。NPEアイデンティティには、ユースケースや環境に応じて、サービスアカウント、ボット、スクリプトなどが含まれます。次に、最もリスクの高いデバイスとそのアクセスを保護する方法を特定します。

ステップ4：アイデンティティ自動化のテストとデプロイ

このステップでは、IDaaS製品の設定と運用を自動化するためのプロセスを説明します。IDaaS製品はそれぞれ異なるため、ここでは技術やベンダーに依存しない手順を提供し、ユーザーエクスペリエンスの形式に従って既存の手動プロセスを文章化します。自動化にはIDaaSのネイティブ機能、スクリプト、APIリクエスト、ツールの統合が必要になる場合があります。

• 1.プロセスの文書化
  プロセスはユーザの視点からの全てのアクションと結果を含むものとします。ステップ1で提供されたユースケースの例に類似した構造で文書化します。
  ＜自動化のための例＞
  ・ユーザアカウントの非アクティブによる停止
  ・アカウントのプロビジョニングまたはプロビジョニング解除（オンボーディング）
  ・特定のグループのユーザに対するアクセス要求の承認
  ・不審な活動の報告
  ・資格情報の登録
  ・PKIトラストストアの管理
• 2.プロセスワークフローのレビュー
  ホワイトボードセッションやユーザがプロセスを実行する様子を観察し、タスク完了に必要な依存関係や問題点を文章化します。このステップはプロセスの徹底的な理解です。
• 3.自動化アプローチの生成
  ワークフローステップを見直して完全また部分的な自動化の可能性を探ります。手動アクティビティには以下が含まれます。
  ・アカウントのプロビジョニングに対する一連の承認（例：従業員のオンボーディング）
  ・データの検証
  ・レポートの生成
  ・リマインダーメールの送信
  ・テスト
• 4.ワークフローのテストと実施
  最適なワークフローが見つかったら、テストして実装します。可能であれば、本番環境以外でテストします。本番環境でしかテストができない場合は、影響を小さなコミュニティのユーザやミッションに重要でないタスクに限定します。

ICAM構成 - アイデンティティ

デジタルワーカーは、自動化されたソフトウェアベースのツール、アプリケーション、またはエージェントであり、人間のユーザと同様のビジネスタスクまたはプロセスを実行し、人工知能（AI）またはその他の自律的な意思決定機能を使用します。

デジタルワーカーのアイデンティティ管理のための3ステッププロセス

このプロセスは、デジタルワーカーのアイデンティティ管理プロセスを構築するための構造化された反復的アプローチです。企業のアイデンティティ管理ポリシーを作成、更新、強化するために使用されます。

ステップ1：デジタルワーカーのアイデンティティを確立するかどうかを決定する

「影響の評価」

デジタルワーカーがネットワークやアプリケーションにアクセスする前に、従来の人間と同じように審査が必要です。ただし、すべてのデジタルワーカーが固有のアイデンティティを必要とするわけではありません。組織のICAMガバナンス構造と連携し、以下を実行します。

• ガバナンス構造とポリシーの作成
  デジタルワーカーアイデンティティ管理の監視のためのガバナンス構造とポリシーを作成または拡張します。
• デジタルワーカー影響評価
  リスクを評価するためのスコアリングツールです。この評価マトリックスは、デジタルワーカーの範囲とアクセスのリスクを6つの要因で数値化します。
• 影響レベルの識別
  総合的な影響をもたらすレベルを決定します。
• 重要ポイント
  影響レベルの低いデジタルワーカーにはデジタルアイデンティティが不要な場合があります。ただし、すべてのデジタルワーカーにデジタルアイデンティティが必要とする場合は、モデレートレベルのプロセスに従います。

ステップ2：組織のICAMポリシーに準拠するアイデンティティを作成する

「スポンサーと管理者の割り当て」

デジタルワーカーにはスポンサーと管理者が割り当てられ、監視役割と責任が設定されます。これにより、以下を実行します。

• スポンサーと管理者を任命
• デジタルワーカーのアクセスレベルを検証
• 最小特権の使用、職務分離、定期的なアクセス再認証などのセキュリティベストプラクティスを遵守

ステップ3：組織のエンタープライズ・アイデンティティ管理システムにアイデンティティをプロビジョニングする

「データ要素のキャプチャ」

スポンサーと管理者を割り当て、アクセスを検証した後、デジタルワーカーのアイデンティティ記録に必要なデータ要素を把握します。これにより、デジタルワーカーのアイデンティティ・ライフサイクルを適切に管理・監視できます。

ICAM構成 - 資格情報管理

多くの組織では、PIV（Personal Identity Verification）をメインの認証手段として使っていますが、スマートカードはすべての場面で適しているわけではありません。

そこで、承認されたセカンダリオーセンティケーター（第二の認証手段）や、フィッシングに強い新しい認証手段を決めるプロセスが重要です。フィッシングに強いセカンダリオーセンティケーターは、高いセキュリティを提供しつつ、ユーザの使いやすさも向上させることができます。

• FIDO（Fast Identity Online）
  より強固な認証方法として使用されることが多い。
• 外部認証の受け入れ
  他の認証手段を組み込むことで、セキュリティを向上させます。

ICAM構成 - アクセス管理

エンタープライズSSO（シングルサインオン）サービスは、組織内のすべてのアプリケーションへの認証を一元化します。これにより、ユーザは複数のアプリケーションに対して単一のポータルまたはアクセスポイントから認証できます。

このシステムは、認証ポリシーを統合し、多要素認証をサポートしていないアプリケーションにも多要素認証を適用することで、セキュリティを強化します。結果として、IDに関するヘルプデスクのコストやタスクが削減されます。

エンタープライズSSOサービスを実装する際の5つのステップ

ステップ1：サポート体制の構築

組織がまだエンタープライズSSOサービスを使用していない場合、最初に計画と予算が必要です。この段階では、SSOのメリットを説明するビジネスケースを作成し、SSO実装後の目標を設定します。

SSOは、複数のアプリケーション間で認証を一元化する技術です。データは「アサーションプロトコル」を使って交換され、主なプロトコルには以下の2つがあります。

• Security Assertion Markup Language（SAML）
• OpenID Connect（OIDC）

これらのプロトコルを使用することで、ユーザは一度のログインで複数のサービスにアクセスできるようになります。

アサーションプロトコル	概要	詳細情報
SAML	認証および承認データを交換するためのXMLベースのオープンスタンダード	SAML2.0の技術概要 （https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html）
OIDC	基本的なユーザプロファイル情報を送信するために使用されるOAuth 2.0承認プロトコルのJSONベースの認証レイヤー	OpenID Connectとは（How OpenID Connect Works - OpenID Foundation）

SSOアクター	概要	SAML用語	OIDC用語
従業員または請負業者	アプリケーションにアクセスしようとしているユーザ	利用者	利用者
エンタープライズSSOサービス	従業員または請負業者の認証を行うサービス。NIST SP800-63ではIDプロバイダーと呼ぶ	アイデンティティ プロバイダー（IdP）	OpenIDプロバイダー
アサーション	ユーザデータとアクセス特権を含む特定のプロトコルを使用して、サービスから証明書利用者にデジタル署名されたメッセージ	SAMLアサーション	IDトークン、JSON Webトークン
アプリケーション	アサーションのコンシューマであり、証明書利用者またはサービスプロバイダーと呼ばれる場合がある。これは、社内ネットワークまたはクラウドサービスに配置される	サービスプロバイダー	リソースプロバイダー

ステップ2：アプリケーション統合の計画

アプリケーションのリストと分析

まず、アプリケーションのインベントリを作成し、分析を行います。これには、組織全体で協力して以下を実施します。

• ネットワークログの確認
• 資産管理台帳の確認
• アプリケーション管理者との話し合い

これらの手順を通じて、組織内で使用されているすべてのアプリケーションのリストを作成します。その後、各アプリケーションについて、以下のような一般的な認証特性を分析します。

• サポートされている認証プロトコル
• ユーザーコミュニティの特性

デジタルIDリスク評価（DIRA）の活用

例えば、デジタルIDリスク評価（DIRA）プレイブックを使用すると、アプリケーションのデータの機密性レベルとユーザ数に基づいたリスク分析を行うことができます（図参照）。この評価結果は、アイデンティティ、オーセンティケーターおよびデジタルアイデンティティ評価ステートメント（DIAS）にまとめられます。

統合とリスク管理

これらの文書は、全体的なリスク管理フレームワーク（RMF）およびFISMAプロセスの一部として使用・統合できます。これにより、アプリケーション統合の計画が組織全体のセキュリティ管理に適切に反映されます。

ステップ3：サービス統合の準備

アーキテクチャのレビュー

まず、アーキテクチャのレビューを実施し、SSO（シングルサインオン）サービスの統合準備を行います。ここで考慮すべきポイントは次の通りです。

• ユーザデータの保存場所の確認
  組織のユーザデータがどこに保存されているかを確認し、そのデータをSSOサービスにどのように接続するかを決定します。
• セキュリティ統合の検討
  セキュリティ情報およびイベント管理（SIEM）や継続的診断および軽減（CDM）ツールとの統合を検討します。

既存コンポーネントの統合

アーキテクチャのレビューで、以下の既存コンポーネントを統合する必要があるかどうかを判断します。

• ユーザアカウントの信頼できるソース（ディレクトリまたはデータベースなど）
• ユーザのプロビジョニングと解除プロセス（ユーザの登録および削除の手順）
• 他のセキュリティツールとの統合（例としてSIEMツールなど）

システム統合と追加のレビュー項目

システム統合に加え、以下の項目もアーキテクチャのレビューに含める必要があります。

• システム設計、ユースケース、セキュリティ計画
  システムがどのように設計され、どのような利用シーンがあるか、セキュリティ対策の計画。
• サポートされている機能、ユーザーインターフェース、ユーザーサポートプロセス、管理ワークフロー
  システムの機能やユーザがどのようにインターフェースを利用し、サポートや管理がどのように行われるか。
• 新しいユーザーコミュニティーサポートのためのアプリケーションレベルのプロセス
  新たにサポートが必要なユーザーグループに対するプロセス。

この準備を行うことで、SSOサービスの統合がスムーズに進み、組織全体のセキュリティと効率が向上します。

ステップ4：使用するアプリケーションを統合する

アプリケーションをSSO（シングルサインオン）サービスと統合するには、以下のプロセスが必要です。

• 1.SSOサービスを使用してアプリケーションを構築
• 2.接続をテスト
• 3.ユーザーコミュニティにアプリをリリース

アプリケーション統合のプロセス

アプリケーションのインベントリと分析によって、SSOサービスと統合するために異なるアプローチが必要な場合があります。費用対効果を考慮しながら、最適な方法を検討します。

• 新しいアプリケーション
  早期導入者やパイロットフェーズを利用して、スムーズなオンボーディングプロセスを確立します。
• 既存のアプリケーション
  段階的な移行を計画し、テストとフィードバックを取り入れながら運用リリースを進めます。変更管理が複雑になることが多いため、慎重な計画が必要です。

構成とデータ共有

アプリケーションの構成には、SSOサービスとアプリケーション間で構成データを共有するプロセスが含まれます。情報の共有方法は、使用するアサーション プロトコルによって異なります。

• SAML（Security Assertion Markup Language）
  SSOサービスとアプリケーション間で接続情報のメタデータファイルを共有する必要があります。これにより、セキュリティで保護された接続とID情報の共有が可能になります。
• OIDC（OpenID Connect）
  構成は通常自動化されており、アプリケーションにログインしてSSOサービスへの接続を承認するプロセスが含まれます。また、SAMLと同様にメタデータプロセスを使用することもあります。

ステップ5：アプリケーション アクセスのフェデレーション

フェデレーションとは、他の機関が管理するデジタルIDや資格情報を共有し、受け入れることを指します。従来、多くのアプリケーションは個別に構成され、様々な資格情報を直接管理していました。この直接管理は、多くの時間とリソースを消費し、管理の複雑さとリスクを増大させます。

直接管理の問題点

直接管理では、ユーザが役割や組織を離れても、アカウントや資格情報がアクティブなままになるリスクがあります。

SSOによる解決策

エンタープライズSSO（シングルサインオン）は、様々な資格情報を統一し、ユーザ管理を簡略化します。資格情報の更新はSSOサービスだけで済み、メンテナンスの変更も一元管理できます。

フェデレーション vs 直接管理の利点と欠点

フェデレーションによるSSOのメリット	直接管理の欠点
更新の簡略化 新しい資格情報や認証子を受け入れるために、更新が必要なのはSSOサービスだけです。各アプリケーションに更新する必要はありません。 メンテナンスの一元化 信頼ストアの管理や失効チェックなどのメンテナンス作業をエンタープライズSSOで統合して行うことができます。 標準化と拡張性 企業全体で一意のユーザIDを標準化し、新しいユーザーグループにも簡単に拡張できます。	個別の更新作業 新しい資格情報や認証子を受け入れるために、各アプリケーションを個別に更新する必要があります。 技術的構成変更の必要 各アプリケーションが相互運用性を維持するために必要な技術的な構成変更を行う必要があります。 独自の識別スキーマの計画 各アプリケーションに独自の識別スキーマを計画・実装する必要があります。他のシステムで再利用できない場合もあります。

エンタープライズSSOのメリット	直接管理の欠点
統一されたセキュリティ管理 SSOのセキュリティ制御を統合されたアプリケーションで共有できるため、一貫したセキュリティ管理が可能です。 集中管理によるユーザ削除 ユーザの削除を一元化し、自動化でき、セキュリティリスクを低減します。 監査とログ管理の効率化 認証に関する監査やログの管理を集中化し、セキュリティツールと効率的に統合できます。	セキュリティ評価の負担 各アプリケーションにセキュリティ制御を評価する必要があり、多大な労力がかかります。 ユーザ削除のリスク 個々のアプリケーションがユーザの削除を認識しないと、不正アクセスのリスクが高まります。 ログ管理の困難さ 監査データやログの収集、標準化、相関分析が難しくなります。

エンタープライズSSOのメリット	直接管理の欠点
ヘルプデスクの統合 SSOにより、ログオンチケットやパスワードリセット、ユーザ設定などのプロセスを統合できます。 チケット削減 自動プロビジョニングと一貫したユーザ体験により、ヘルプデスクのチケット数が減少する可能性があります。	個別のヘルプデスク運用 各アプリケーションにヘルプデスクを運用・維持する必要があり、認証に関するサポートを含める必要があります。

図は、直接管理方式の冗長な作業を示し、フェデレーションによる効率的な構成を示しています。

他の組織との連携

フェデレーションは、他の組織とのSSOサービスの連携を可能にします。これにより、他の組織のIDを受け入れ、重複するデータ収集やユーザIDの発行を最小限に抑えます。

計画上の考慮事項

フェデレーションを導入する際の計画ポイントは以下の通りです。

• アプリケーションに必要なユーザIDや属性の特定
• DIRAまたはDIASを通じて識別されたフェデレーション保証レベルで、プロトコルや属性に関する組織間のインターフェース制御や合意の保存・共有

各アプリケーションの統合は、同様の構成、テスト、リリースパターンに従う必要があります。

• IDプロバイダーへのリダイレクト・リンク、またはアプリケーション ログインページのボタン
• テストの実施
• システム変更の計画
• ユーザーコミュニティへの段階的な展開計画
• 定期的なリリース

セキュアなクラウドビジネスアプリケーションのIDaaSについて

近年、多くの組織がクラウドベースのIDaaSプロバイダーを利用して、クラウド上で直接認証を行うアーキテクチャを採用しています。

責任分担モデル

このアーキテクチャでは、IDaaSプロバイダーがプラットフォームの主要なセキュリティコンポーネントのセキュリティを担当し、組織は構成の安全性に責任を負います。脅威の監視などの一部の責任は、組織とベンダーが共有します。

アクセス管理の重要性

• ICAMの役割
  クラウドアプリケーションのセキュリティ確保には、ICAMが不可欠です。ICAMの多くの部分（アイデンティティ・ライフサイクル管理、ルート資格情報の発行、特権役割の割り当てなど）は、企業全体で管理する必要があります。
• 特定のアクセス管理の設定
  一部のアクセス管理はクラウドビジネスアプリケーション内で設定されます。これは、エンドユーザーアクセスの管理において重要です。

強力な管理制御と最小特権の重要性

• 管理制御
  エンドユーザーアクセスを管理するためには、強力な管理制御と最小特権の原則が重要です。
• 条件付きアクセスポリシー
  M365の条件付きアクセスやGoogle Workspaceのコンテキスト・アウェア・アクセスなどのポリシーにより、許可された最新のデバイスにのみアクセスを制限できます。これらのポリシーは、セキュア・クラウド・アクセスとエンドポイント保護技術を結びつけ、組織のデータが望ましいセキュリティ態勢を持つデバイスからのみアクセスできるようにするために有効化されるべきです。

ICAM構成 - フェデレーション

フェデレーションとは

フェデレーションは、他の組織が管理するデジタルID、属性、資格情報を受け入れるための技術、ポリシー、標準、プロセスを指します。これは、単一組織内だけでなく、複数組織間でもデジタルIDの共有と受け入れを可能にします。

フェデレーションの仕組み

FICAMにおけるフェデレーションは、他の組織が管理するデジタルIDや資格情報を共有するために、OpenID Connect（OIDC）やOAuth 2.0などを使用します。OIDCはエンドユーザーの認証を行い、OAuth 2.0は属性に基づく権限を管理します。

SSO（シングルサインオン）はこれらのプロトコルを利用して、デジタルIDを他の機関やアプリケーションと共有します。

エンタープライズSSOの推奨

エンタープライズSSOを利用することで、資格情報の直接管理に伴う複雑さとリスクを軽減できます。SSOベースのフェデレーションでは、資格情報またはオーセンティケーターに関係なく認証トランザクションが標準化され、ユーザ管理アクティビティが統合されます。

フェデレーションの前提条件と制約

NIST SP 800-63Cの要件を満たす必要があり、セキュリティおよびアイデンティティ属性の交換手順とプロトコルを確立する必要があります。フェデレーションのメンバーは、エンティティにアクセス（認証）を許可する条件および認可の範囲に関する条件を公開し、合意します。

他組織のICAMサービスを利用する場合、関係をフェデレーションの全メンバーに周知し、機密性、完全性、可用性を維持する必要があります。

フェデレーションの機能：認証（IDP）

認証機能

• エンティティのアイデンティティや属性を検証します。
• 有効な属性を持つ正規のエンティティのみがアクセスを許可されます。
• 属性の形式と有効性を確認します。

認証の要素

• 資格情報の検証
  提示された資格情報の完全性、出所、信頼性を確認し、有効期限切れ、取り消し、無効化されていないことを確認します。
• 要素の検証
  「知っていること」「持っていること」「あること」などの要素を検証し、資格情報が発行された個人と提示者が一致することを確認します。
• セッション管理
  複数のエンティティが同時にインフラにアクセスする際の認証およびタイムアウトポリシーを適用します。
• ポリシーの整合
  権限、ポリシー、標準通信プロトコル、原則を確立して信頼関係を構築します。
• 認証ブローカー
  認証イベントをアサーションに変換し、エンティティや認証取引に関するクレームや属性を含む形式でリソースへのアクセスを許可します。

フェデレーションの機能：認可（サービスプロバイダー）

認可機能

エンティティにアクセス権限を付与し、エンティティや環境のコンテキストに関する情報をマッピングします。

認可の要素

• ポリシー決定
  アクセス制御ポリシーに基づいてアクセス制御決定を行います（許可、拒否、条件付き許可）。
• ポリシー実施
  ポリシーに基づいてアクセス制御決定を実行します。
• 属性交換
  異なるエンタープライズドメインやクラウドホステッドアプリケーション間でアイデンティティ属性を発見し、共有します。

ゼロトラスト・アーキテクチャの構築

ゼロトラスト・アーキテクチャは、ネットワークの内外を問わず、全てのアクセスを検証してから、信頼するというセキュリティモデルです。

フェデレーションは、このモデルにおいて、複数のドメイン間での認証と権限付与を安全に行うための鍵となります。このように、クラウドサービスの提供とゼロトラスト・アーキテクチャの構築において重要な役割を果たします。

フェデレーションの役割

フェデレーションは、異なる組織やサービス間で信頼関係を確立し、安全にリソースを共有するための仕組みです。よって、同じ信頼ドメイン内では、アサーション・プロファイルを使用して、認証情報や権限情報を共有します。

フェデレーション・トラスト・フレームワークの構築

フェデレーションを構築するためには、以下の要素が含まれます。

• ガバナンス：管理と運営の枠組み
• 技術およびセキュリティ要件：フォーマットや属性などの技術仕様
• 法的合意：法的に認められた契約や合意
• 適合基準：公開鍵インフラストラクチャ（PKI）に基づく第三者監査
• 承認：PKIメンバーリソースの使用に関する許可

IDaaSがフェデレーションとSSOの両方をサポート

IDaaSは、フェデレーションとSSO（シングルサインオン）の両方をサポートします。これにより、ユーザは一度の認証で複数のサービスにアクセスでき、利便性とセキュリティが向上します。

ICAM構成 - ガバナンス

ガバナンスとは、ICAMの機能、活動、成果を導く一連の実践とシステムを指します。具体的には、FICAMアーキテクチャの中でガバナンスフレームワークがどのように構成されているかを見ていきます。

ICAMガバナンスフレームワーク

• 組織フレームワーク
  ICAMフェデレーションをサポートするために、プログラムガバナンスとリーダーシップが必要です。
• ハイレベルフレームワーク
  ガバナンスとリーダーシップのための枠組みが含まれており、役割と責任を明確にしたプログラムガバナンス機関の推奨がされています。
• コンポーネントガバナンスチーム
  ICAM関連のプログラムマネージャーとIT専門家によるチームが設立される必要があります。

プログラムマネジメントオフィス（PMO）

• PMOの役割と責任
  PMOは、FICAMを支援するための重要な組織であり、その役割と責任が明確に定義されています。
• PMOガバナンス構造の確立
  PMOのガバナンス構造も確立される必要があります。

ガバナンス・クラウド・コンセプト

ガバナンスのためのクラウド・コンセプトには以下のポイントが含まれます。

• アプリケーションの所有者や管理者へのアクセスを認証
• IDaaSの可用性を検証するために、不測の事態に備えた計画立案
• システム設定の構成変更を監視
• ポリシーに基づいたガバナンスを構築
• 全ユーザのアクティビティログを監視

CISA ゼロ・トラスト・ガバナンスの成熟度モデル

CISA（Cybersecurity and Infrastructure Security Agency）のゼロトラスト成熟度モデルは、ガバナンスがすべての柱と基礎レイヤーを支える重要な要素であることを示しています。特にアイデンティティの柱について、成熟度の違いが認識されています。

• 従来型
  クレデンシャル・ポリシー（複雑性、再利用、長さ、クリッピング、MFAなど）を使用し、最初のプロビジョニング後にIDと権限を手動で監査します。
• 高度
  ポリシーベースの自動アクセス失効を使用し、共有アカウントはありません。
• 最適
  ポリシーの技術的な実施を完全に自動化し、新しいオーケストレーション・オプションを反映するためにポリシーが更新されます。

最後に

前編の振り返り

ゼロトラスト・アーキテクチャを実装する企業には、トラステッドなID、資格情報、アクセス管理を総称するICAMおよび資産管理システムの導入が推奨されます。しかし、最新の実態調査によると、「ソフトウェアライセンス管理/IT資産管理製品」の導入率は28.8%から16.9%、「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」は19.0%から6.2%、「セキュリティ情報管理システム製品（ログ情報の統合・分析、システムの総合的な管理機能）」は24.5%から11.2%に低下しています。

これは従来の境界中心のICAMアーキテクチャが、手作業で行うコンフィグレーションは非効率的で、手間もかかり、ミスが発生しやすい問題がありました。更にADは特権の昇格、パスワードやハッシュの漏えいに対して脆弱であることも挙げられます。

そこで、クラウドサービス・プロバイダー（CSP）を使用したクラウドサービスの導入によって、アクセス管理が効率的に行える、クラウドアクセス・セキュリティブローカー（CASB）を用います。

つまり、ZTAの要件では、すべてのリソースの認証と承認は動的であり、アクセスが許可される前に厳格に適用する必要があります。

後編のまとめ

これを実現するためには、セキュリティ、可用性、使いやすさ、およびコスト効率のバランスが重要です。強力なアイデンティティ管理と成熟したICAM能力は、NPE（Non-Protected Entities：非保護エンティティ）に対しても必要とされます。ゼロトラスト成熟度モデルを通じて、これらの能力を高めることが求められます。

その基盤として、Cloud Identity戦略は、組織が協調して機能するために役立ちます。戦略と目標の統合が重要であり、これを基に構成された5つのコアサービスとサブサービスのICAM実践領域とサービスフレームワークを活用することで、セキュリティ、可用性、ユーザビリティ、およびコスト効率のバランスを達成するポリシーを定義します。さらに、再認証および再認証の可能性を伴う継続的な監視をユーザートランザクション全体に渡って実施します。

これが「すべての資産の認証と認可は動的に行われ、アクセスが許可される前に厳格に実施する」という考え方に基づいた取り組みとなります。

経験豊富な専門家に相談を

つまり、ゼロトラスト移行にあたっては道に迷わないように、情報セキュリティプランニング（セキュリティリスクの可視化、対策立案、ロードマップ作成）が必要です。また、保護に必要なソリューション（セキュリティ製品やサービス）を導入することになるため、手戻りを防ぐためにも実装経験が豊富なSIベンダーからアドバイスをもらうことをお勧めいたします。

今回は、NISTによるゼロトラストの考え方の6番目に当たる「全ての資産の認証と認可は動的に行われ、アクセスが許可される前に厳格に実施する」について解説しました。次回は最後にあたる「企業は、資産やネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、それをセキュリティ対策の改善に利用する」について、ラックの考えるゼロトラストをお伝えいたします。