View on GitHub

bok

IDPro Body of Knowledgeの日本語訳を載せていきます

IAMアーキテクチャ入門

アンドリュー・キャメロンとグラハム・ウィリアムソン

© 2020 Andrew Cameron, Graham Williamson, IDPro

注：IDPro BoKは、特定のアーキテクチャ・フレームワークを推奨するものではありません。IAM実務者は、多くの異なるアプローチに直面し、IAM実務者は、その組織に最も適したモデルを採用する必要があります。

序章

IAM（Identity and Access Management）は、組織のIT環境のあらゆる側面に触れています。それが人事（HR）システムであれ、電子メールシステムであれ、電話システムであれ、企業のアプリケーションであれ、各システムはIAM環境にインターフェースする必要があります。IAMは、例としてユーザーのプロビジョニングルールの施行をサポートしたり、企業以外のユーザーのアクセスを検証したりすることで、IT運用を効率的かつ安全にする役割を常に担っています。IAMシステムを開発するためのアーキテクチャ・アプローチは、組織が一貫性のある包括的なIAMソリューションを実現する確率を高める。

組織がエンタープライズ・アーキテクチャ（EA）を維持している場合、展開するIAMソリューションはすべてエンタープライズ・モデルに準拠し、組織のEAアーティファクトに反映されていなければなりません。この記事では、IAMの専門家がEAがあるかどうかを検討するための基本的なアプローチを提供します。

用語解説

アクセス管理：コンピュータシステム、データベース、または物理空間などの保護されたリソースへのアクセス制御を提供するための ID 情報の使用。

アーキテクチャ : 情報技術インフラストラクチャの設計、展開、運用のためのフレームワーク。これは、組織が使用する技術を標準化し、そのITインフラをデジタルトランスフォーメーションポリシー、IT開発計画、およびビジネス目標と整合させることができる構造を提供します。

アーキテクチャの概要 : 企業全体でIAMをサポートするために必要なアーキテクチャコンポーネントを説明します。

アーキテクチャ・パターン：組織内のITインフラストラクチャ・アーキテクチャを分類し、IAMソリューションの展開の選択の指針となる本質的なパターンを識別します。

エンタープライズ・アーキテクチャ：情報技術（IT）環境のすべてのコンポーネントをカバーするアーキテクチャ

ID ガバナンスおよび管理（IGA）：ID 情報の収集および使用には、ID 情報の収集および使用のほか、適切な人物が適切なシステムに適切な時に適切なアクセスができるようにするためのガバナ ンスプロセスが含まれる。

頭字語

BPMn - ビジネスプロセスマッピング表記法

HTTP - ハイパーテキスト転送プロトコル

JSON - データ属性を通信するためのファイル構造体

RESTful API - HTTP メソッドの使用方法を定義するプログラミングインターフェイスのアーキテクチャ

SAML - セキュリティアサーションマークアップ言語

SCIM - クロスドメインアイデンティティ管理システム

XML - eXtensible Markup Language - データ属性を通信するためのファイル構造。

IAMアーキテクチャの概要

IAMの専門家は、企業の要求を満たすIAM環境のビジョンを持っていなければなりません。各IAMプロジェクトは、望ましい目標状態に向かって構築しなければなりません。アーキテクチャ・アプローチにより、IAM の専門家は、調整され統合された IAM ソリューションを計画、設計、展開し、企業の利害関係者の現在のニーズと予測されるニーズの両方を満たす包括的な IAM 環境を形成するために組み合わせることができるようになる。

企業内のアイデンティティ管理は、組織内で使用されている事実上すべてのシステムに影響を与える。システムは、この文脈では、スタッフやビジネス・パートナーが職務上の責任を果たすために使用するコン ピューター・システムと、制限された領域へのアクセスを得るために ID パスを提示する必要があるなどの物理的なアクセス・システムで構成されている。スタッフには請負業者も含まれます。彼らは通常、別のシステムで管理されていますが（多くの人事システムは従業員のみに対応しています）、従業員と同じ会社のシステムの多くにアクセスする必要があります。人間以外のアカウントを含めることも考慮する必要があります。ほとんどの組織では、システムへのマシンアクセスのためのサービスアカウントを持っています。企業のオペレーションに自動化がより多く組み込まれるようになると、センサーやボットへのアクセス制御を提供することをIAM環境に組み込む必要があります。人間以外のエンティティをアーキテクチャに含めることで、企業は他のすべてのアカウントと一貫した方法でアクセス制御を管理することができます。

企業内で ID 情報が使用される場合はいつでもどこでも、効率性を確保し、プライバシーを保護し、 完全性を保護する適切に設計された環境で情報が収集され、使用されることを保証することは、IAM 実務者の仕事である。アーキテクチャ・アプローチ、すなわち構造化されたフレームワーク内でプロジェクト要件を開発することで、IAM プロジェクトが利害関係者への影響を抑制しながら一貫して包括的に完了する可能性を大幅に高めることができる。

IAMの実務家がソリューション・アーキテクチャを開発する際に考慮すべき4つのレベルがあります。

モニターからアクセスするメインフレーム・アプリケーションによるシンプルな構成

図1 - 一般的なエンタープライズ・アーキテクチャ・フレームワーク

ビジネスシステムアーキテクチャ(BSA)

IDデータの収集、使用、および最終的な削除のためのビジネス・プロセスをマッピングすることは、IAMタスクの幅広さを理解する上で大いに役立つ。ビジネスプロセスのマッピングにはBPMnが一般的に使用されているが、IAMの実践者は、自社で一般的に使用されているツールを採用すべきである。

ビジネスレベルでITアーキテクチャを考慮することで、接続されているすべてのシステムのアイデンティティ要件を考慮し、命名規則の一貫性を保証する、より全体的なアプローチが促進されます。また、IAMプロジェクトが予算超過や時間超過で実行される可能性を減らすことができます（以前に相談を受けたことのないシステムオーナーがIAMプロジェクトについて聞いて、予期せぬ要件を追加することはよくあることです）。

情報アーキテクチャ

さまざまなアプリケーションで必要とされる ID データ要素を、IAM 収集、管理、および統治システムにマッピングすることが重要である。このマッピングにより、IAM システムが再開発されたときにアプリケーションが「取り残される」ことはない。有用なツールは、収集した各属性をそれを必要とする各システムにマッピングする「実体関係図」である。情報アーキテクチャ(IA)は、接続されたシステム間の一貫性を促進すべきである(例えば、ファーストネーム、ミドルイニシャル、ラストネームを使用すべきか、コモンネーム、ラストネームを使用すべきか)。また、役割の定義にも役立ちます（例えば、この役割は給与計算担当者や財務担当者のためのものです）。IAは、属性の権限（例えば、どのシステムが電話番号の権限を持っているか）を指定すべきである。ベストプラクティスは、IAM システムが社内の ID 情報の「真実のソース」であることである（「記録の書」と呼ばれることもある）。

IA は「ID データ・オーケストレーション」のための手段になる。IA は、企業内での ID データの収集と使用のためのマスタープランである。

アプリケーション・ポートフォリオ

ＩＡＭプロジェクト１の対象となるアプリケーションのインベントリを実施すべきである。それらのアプリケーションはどの程度最新のものですか？含まれるアプリケーションの中に開発中のものはありますか？IAMプロジェクトは、各アプリケーションがIAM環境と相互作用する方法を大きく変えるのか？例えば、IAM属性へのアクセスのためにAPIゲートウェイが展開されている場合、アプリケーションの再開発は、既存の認証メカニズムからゲートウェイ操作に移行する必要があります。

企業のアプリケーション・ポートフォリオ（AP）は、企業のアプリケーションのインベントリになります。各アプリケーションのレコードは、システムの所有者、アプリケーションのタイプ（Webアプリ、クライアント・サーバー、メインフレームなど）、およびIAM環境への依存度を識別する必要があります。アプリケーションの中には、IAMシステムに認証済みセッションを渡すことを期待するものもあります。対照的に、他のアプリケーションでは、ユーザーがアプリケーションの機能に対して持っている認証を決定できるように、ユーザーの属性を要求するでしょう。APは、各依存アプリケーションとIAMシステムとの間の統合レベルを特定すべきである。Web アプリケーションは、HTTP ヘッダーを介してユーザのリクエストとレスポンスを渡すことが多いでしょう。他のシナリオでは、クライアント・サーバ・アプリケーションは API を使用し、クラウド・アプリケーションは SAML リクエストを使用するか、独自のデータリポジトリを維持している場合は SCIM プロトコルを使用する。2

APは組織にとって重要な記録となり、アプリケーションが更新されたときに必要とされる計画を容易にします。

技術アーキテクチャ

テクニカル・アーキテクチャー(TA)は、特にIAM環境でサポートされる技術環境を記述します。この記述には、社内で使われているパターンを理解することが含まれます。ほとんどの組織では、「n層」のウェブサービスやハイブリッドクラウドのパターンがあるだろうが、クライアント・サーバーのパターンや、メインフレームのハブアンドスポークの可能性があるパターンもまだあるかもしれない。対応するパターンが増えるごとに、プロジェクトの複雑さとコストが増大します。RACFディレクトリなどの古いインフラストラクチャを持つIAM環境では、コストを考慮してレガシー技術のサポートを省くことがよくありますが、これではIAMタスクが断片化してしまいます。適切に構成されていれば、RACF コネクタの展開のためのコスト/便益分析は通常成功する。

異なるパターンには異なるソリューションが必要とされるため、TA は IAM 環境に影響を与える。例えば、Web サービス・パターンでは、RESTful API と SAML アサーションをサポートし、ID 属性を JSON 配列または XML ファイルに渡すことができるシングル・サインオン (SSO) 環境が必要となる。別の例として、オンプレミスの Windows 環境では、通常、AD インフラストラクチャまたは LDAP ディレクトリからの Kerberos 認証プロトコルが使用されます。クラウド環境では、SAML 操作や IDaaS の提供が必要になることが多く、RACF ディレクトリは IAM インフラストラクチャからのコネクタを介してサポートされる必要があります。

アーキテクチャ・アプローチ

多くのIAM（アイデンティティとアクセス管理）プロジェクトが、予定していた時間と予算を超過しているのは不幸な事実です。この原因としてよくあるのは、プロジェクトの範囲と影響を受けるシステムに対する誤解です。プロジェクトチームは、企業内のIAMシステムが組織内で使用されている事実上すべての他のシステムに触れていることに気づかずに、手元のタスク、例えば、IAMソフトウェアパッケージのインストールだけに焦点を当てる傾向があります。これらの他のシステムは、電子メールのような誕生日システム、財務管理システムのような管理システム、またはエンタープライズリソース管理システムのような運用システムを含むかもしれません。

ある状況では、IAMプロジェクトによって引き起こされる変更は、リソースへの影響が限定された最小のものになります。他のケースでは、変更は組織全体のインフラストラクチャと人員の両方に影響を与え、重大なものになります。アーキテクチャ・アプローチでは、各IAMプロジェクトのためにソリューション・アーキテクチャが開発され、必要とされる作業の範囲を理解し、それがもたらす変化を効果的に計画することが保証されます。

企業内で ID 情報が使用される場合はいつでもどこでも、効率性を確保し、プライバシーを保護し、 完全性を保護する適切に設計された環境で情報が収集され、使用されることを保証することは、IAM 実務者の仕事である。

エンタープライズ・アーキテクチャを持つ組織の場合、情報がどのように収集され、どのように使用されるかを理解することは、 システムの展開方法の基本的な部分であるため、非常に簡単であるはずである。他の組織では、環境は「グリーンフィールド」であり、IAMの実践者が独自のアーキテクチャアプローチを開発することを可能にします。

アーキテクチャーパターン

技術アーキテクチャのレベルでは、「パターン」アプローチは、組織内でサポートされている技術を理解するのに便利です。例えば、主要なサーバーインフラストラクチャは何か - LinuxかWindowsか、またはその両方か？どのようなサーバーオペレーティングシステムのバージョンがサポートされているか？VMは使用されているか？クラウド・インフラストラクチャのサポートは何か - パブリック、プライベート、ハイブリッド？AWS、Azure、Google Cloudはサポートされていますか？顧客のIAMに必要なスケールに対応できるか？IoTデバイスの場合、IoTプラットフォームは企業環境とどのように統合されているか？

TAは、組織内のIAM環境でサポートされるコンピュータシステムの「パターン」を定義します。若い企業の場合、これはウェブベースのパターンであり、”2層 “または “n層 “のいずれかになるだろう。管理されたクラウド環境では、マイクロサービスのアプローチを採用するケースが増えています。しかし、成熟した組織では、一般的に、クライアント・サーバー・パターンのレガシー・アプリケーションや、ターミナル・エミュレータ・ソフトウェアを実行するPCを備えたメインフレームの「ハブ・アンド・スポーク」パターンが存在することになります。

IAM環境は、選択されたパターンをサポートし、組織のガバナンスとサイバーセキュリティポリシーに準拠した管理されたアプローチを保証しなければなりません。

ホスト

メインフレーム・システムは、銀行業界や一部の政府機関では顕著な例外を除き、現役で使用されているものはほとんどありません。IAM環境では、メインフレーム・システムをサポートするためにRACFデータ・ストアに同期する必要があります。

モニターからアクセスしたメインフレーム・アプリケーションによる簡単な構成

図2 - モニタからアクセスするメインフレームアプリケーション

クライアント・サーバー

クライアント・サーバ環境は、多くのシステムがシステム機能にきめ細かいアクセス制御を提供するために独自の ID データベースを維持しているため、複雑なサポート要件を提示する可能性があります。クライアント・サーバ・アプリケーションを再開発して、アクセス制御の決定を本物の認証サーバに外部化することは、組織全体のアクセス・ポリシーを調和させる方法となります。

シンプルなクライアント・サーバ・ネットワーク図

図3 - クライアントアプリケーションのバックエンドサーバへのアクセス

N層

最近の最も一般的なオンプレミスのアプリケーション環境は、「n 層」のウェブサービスインフラストラクチャです。多くのバリエーションがありますが、フロントエンドのウェブサーバにアクセスするユーザは、認証サービスにリダイレクトされ、通常はSSOをサポートし、認証トークンがHTTPヘッダでアプリケーションに渡されます。アプリケーションがユーザ認証を必要とする場合、IAM システムは、ユーザが組織に参加する際に、初期のプロビジョニング活動の一部としてユーザ権限を設定しなければなりません。

クライアント・マシンがネットワークを介してプレゼンテーション・サーバ、アプリケーション・サーバ、およびデータベース・システムに接続している図。

図4 - 一般的なWebサービスモデル

ハブ＆スポーク

ハブアンドスポークシステムは、通常、大規模なトランザクション処理システムにのみ存在します。多くの場合、IAMの唯一のタッチポイントは、特権アクセス管理システムを介したDevOpsスタッフのアクセス制御です。

2つのクライアントシステムがネットワークを介して「ETL」ホストに接続し、内部データベースと外部データベースに接続します。

図 5 - 共通データサービスの構成

リモートアクセス

企業システムへのリモートアクセスをサポートする必要が増えています。認証サーバは、パスワードアカウントのための基本的な LDAP 検索から、アプリケーションのセキュリティ要件に合わせて認証レベルを上げることができる高度な MFA 環境まで、使用される必要なアクセス制御メカニズムに対応する必要があります。このような環境でのプロビジョニング・タスクは、企業内で 1 つ以上の ID プロバイダ・サービスの保守を必要とする。

Web アプリケーション・ファイアウォールまたは VPN を介して外部のリモート・デバイスから企業アプリケーションへのアクセスを提供する典型的な企業モデル

図 6 - 典型的なエンタープライズ・ネットワーク・アクセス・モデル

クラウド環境

最近ではほとんどの組織がクラウドサービスを採用しており、IAM環境はその採用パターンに対応したものでなければならない。100%クラウドである場合もあれば、クラウドとオンプレミスのハイブリッド環境である場合もある。クラウドでは、プライベート・クラウド・インフラやパブリック・クラウド・プラットフォームのいずれかを採用することもあるだろう。IAM の専門家は、依存するアプリケーションが最新の ID データによってサービスされるように、選択されたパ ターンがサポートされていることを確認しなければならない。

左からインターネット・クラウドに接続しているクライアント・マシンは、プライベート・クラウドとパブリック・クラウドにアプリケーション、IDaaS、およびSaaSアプリケーションが含まれている。右側では、オンプレミスのアプリケーションと IdP もクラウドに接続しています。

図7 - クラウドベースのアーキテクチャモデル

組織がサポートするアーキテクチャ・パターンは、情報通信技術（ICT）の運用を維持するためのコストに直接影響します。各追加パターンは、全体的なコストを増加させます。IAM環境は、使用中のパターンをサポートしなければならず、企業がインフラストラクチャの複雑さを軽減する際には、パターンの合理化に対応しなければなりません。例えば、一般的に認証にRACFを使用しているメインフレーム・システムを退役させる企業は、代替ソリューションが必要になります。IAMの実務家は、IAM環境が企業の方向性をサポートすることを保証するために、ICT開発プログラム全体に関与する必要があります。

アーキテクチャー・アプローチの適用

アーキテクチャ的なアプローチは、保護されたリソースへのアクセス制御に ID 情報を使用して、ID 情報の収集と管理、またはアクセス管理に関係なく、IAM プロジェクトに取ることができます。

ID ガバナンスと管理

ID ガバナンスと管理（IGA）は、ユーザーが保護されたリソースへのアクセスを要求したときに発生す る「リアルタイム」イベントとは対照的に、ユーザーの権限を確立する「管理時」イベントなど、IAM の ID 管理側をカバーする。IGA は、ID 情報の収集、使用、および廃棄に関する管理とガバナンスを組み合わせたものである。それには、管理者がそのスタッフが付与された権限を証明することを可能にするガバナ ンス機能が必要である。さらに、IGA には通常、企業要件をサポートする ID サービスの監視および報告機能が含まれている。

IGA システム・サポート。

アカウントおよびクレデンシャルの管理

アイデンティティとアカウントのプロビジョニング

エンタイトルメントの管理

業務分掌

役割管理

アナリティクスとレポート

IGAシステムは、標準的なIAMシステムを超える追加機能を提供します。特に、組織がコンプライアンス要件を満たし、コンプライアンス報告のためにアクセスを監査できるようにします。また、アクセス承認やプロビジョニング/デプロビジョニングなどのタスクのワークフローを自動化します。

アイデンティティのライフサイクル

これらの要素を結びつけるビジネス・ルールは、一般的に「Identity Lifecycle」と呼ばれる。ID ライフサイクルでは、保護されたリソースへのアクセスを必要とする人や物（人間か非人間か）を定義する ID が作成される。Identity Lifecycle の各段階では、企業の ID およびセキュリティ・ルールに従ってビジネス・ルールが確実に実施されるように、ID の活動が管理されている。

Identity Lifecycle の図は、Identity Onboarding から始まり、Identity Management、Account Management、Entitlement Management、および Access Management の順である。

図 8 - アイデンティティのライフサイクル・カテゴリ

IGAシステムコンポーネント

ID ガバナンスおよび管理ツールは、ID ライフサイクル管理の促進に役立つ。

IGA システムには、一般的に、ID 管理のための以下のコンポーネントが含まれています。

パスワード管理 パスワード保管庫や、より多くの場合は SSO などのツールを使用することで、IGA は、ユーザーがアプリケーションにアクセスするために多くの異なるパスワードを覚える必要がないことを保証します。

統合コネクタ。これらのコネクタは、ディレクトリやその他のシステムと統合するために使用され、ユーザー、ユーザーがアクセスできるアプリケーションやシステムに関する情報、およびそれらのシステムでのユーザーの権限に関する情報が含まれています。

アクセス要求承認ワークフロー : これらのワークフローは、アクセス要求の自動化をサポートします。これらのワークフローは、アプリケーションやシステムへのユーザーのアクセス要求の自動化をサポートし、すべてのアクセスが適切に承認されるようにします。

自動化されたデプロビジョニング : これは、ユーザーがシステムへのアクセスを許可されなくなったときに、ユーザーがアプリケーションにアクセスする権利を削除することをサポートします。

Attestation reporting : これは、様々なアプリケーション（データの追加、編集、表示、削除など）におけるユーザーの権限を定期的に検証するために使用され、通常はユーザーのマネージャーに送信されます。

ユーザー権限の再認証 . 多くの場合、認証レポートへの応答として、ユーザー資格の再認証には、マネージャーがスタッフのシステムアクセスを承認したことを記録することが含まれます。アクセスが不要になった場合は、自動デプロビジョニングに移行します。

職務の分離 . IGAシステムには、危険なアクセス権が人に付与されないようにするためのルールがあることが多いです。例えば、ある人が企業の銀行口座を閲覧する能力と外部口座への資金移動の能力の両方を持っている場合、これにより、あるユーザーが個人口座への資金移動を可能にする可能性があります。

アクセスレビュー : これらのレビューには、さまざまなアプリやリソースへのユーザーのアクセスのレビューや検証（または取り消し）を合理化するツールが含まれます。IGA ツールの中には、付与された権限を特定するのに役立つディスカバリー機能を提供するものもあります。

役割ベースの管理 . 役割ベースのアクセス制御（RBAC）としても知られており、これには、ユーザーの役割を介したアクセスの定義と管理が含まれます。

分析とレポーティング : アクティビティをログに記録し、レポートを作成（コンプライアンスを含む）し、問題を特定して最適化するための分析機能を提供するツールが含まれます。

IGAソリューションアーキテクチャ

IGAソリューションがどのようにして認証サービスをサポートし、認証サービスを提供することができるかの例を図8に示す（コンテキストのために示されたアクセス管理）。

アクセスゲートウェイを経由して認証サービスにアクセスするエンドユーザーを含む、IAM アーキテクチャのコンポーネントの図。また、IAサービス、アカウント管理サービス・エンタイトルメント管理サービス、およびエンタープライズ・アプリケーションを介して、エンドユーザーのオンボードおよびオフボードおよび管理を処理する管理ユーザーもいます。

図 9 - IAM アーキテクチャのコンポーネント

本アーキテクチャは、以下のIAMプロセスをサポートしています。

プロセスの説明 ID プロビジョニング 信頼できる ID ソース (HR システムなど) からの開始に基づいて ID レコードを作成する。 アカウントのプロビジョニング 誕生時のプロビジョニングルールに基づいて、エンタープライズディレクトリにアカウントを作成します。また、リクエスト/承認ワークフローに基づいたアプリケーションアカウントの作成もサポートします。 エンタイトルメント管理 アクセス管理ルールの作成を可能にする、ユーザーとグループ/ロールのマッピングを可能にするワークフローと管理要件をサポートします。

アクセス管理

アクセス管理はIAMの「リアルタイム」コンポーネントです。これは、企業のリソースを保護し、デジタル・ビジネスを確保する上で重要なプロセスを網羅しています。電子商取引を可能にするために顧客にアクセス権を与えたり、パートナーが安全にビジネスを行うためにリソースを確保したりする場合でも、アクセス管理アーキテクチャは、実現する技術の計画、設計、および開発を制御します。

アクセス管理の概要

アクセス管理アーキテクチャは、保護された企業リソースに対するアクションの実行を許可されたアカウントのみを有効にするコンポーネントを備えています。

アクセス管理アーキテクチャでサポートされる主な機能は以下の通りです。

ユーザー認証（スタッフ、請負業者、ビジネスパートナー

アクセスポリシー管理

アクセスポリシー 意思決定と執行

認可管理（粗目・細目

アダプティブアクセス制御

シングルサインオン(SSO)

認証セッション管理

セキュリティトークンサービス

アクセスイベントロギング

ユーザー行動分析

アクセス管理ソリューションのアーキテクチャ

ほとんどのシナリオでサポートされている最も一般的なアクセス管理サービスは以下の2つです。

認証 - コンピュータシステムへのログイン - 通常はロールベース

認可 - コンピュータシステムの機能へのアクセス - 通常は属性ベース

ポリシーベースの認証は、ますます展開されています。これは、システムごとに確立されたエンタイトルメントではなく、中央で管理された企業ポリシーに従って企業リソースへのアクセス制御を提供します。

詳細な認可環境の例を図9に示します。ソリューションのコンポーネントは、決定ポイントのポリシーに基づいて企業リソースへのアクセスを制御するために結合されています。

ポリシー施行ポイント（PEP）、ポリシー決定ポイント（PDP）、ポリシー・アクセス・ポイント（PAP）、およびポリシー情報ポイント（PIP）を含む、さまざまなアクセス管理コンポーネント間の関係の図。

図 10 - 認可サービスの代表的なコンポーネント

認可サービスのアーキテクチャは、通常、企業の境界内（ネットワークファイアウォールの後ろ）に存在するアプリケーションやサービス（通常はインターネット上）にアクセスするデバイス（モバイルまたはデスクトップ）上のアクター（人またはシステム）からのフローに関与する主要な要素を含むでしょう。

ポリシー管理ポイント（PAP）は、ユーザーを役割やグループに結びつけ、リソースへのアクセスのタイプを定義するポリシーステートメントを作成する責任があります。 リソースの保護を担当するポリシー施行ポイント (PEP) は、リソースへのトラフィックを遮断し、PDP でアクセスを検証します。 ポリシー決定ポイント（PDP）は、リソースへのアクセスを決定し、ポリシーを使用して、サブジェクト（ユーザー）がリソースへのアクセスを持っているかどうかを決定します。 ポリシー情報ポイント（PIP）は、通常、管理されているユーザー（Active DirectoryやLDAPディレクトリなど）に関する情報を提供するユーザーまたは属性ストアです。

アクセス管理のパターン

よく練られた IAM アーキテクチャは、接続されたオーケストレーションされたフレームワークでアーキテクチャ・コンポー ネント間のフローを組み合わせることで、ユーザー・エクスペリエンスを向上させ、セキュリティを向上させることができます。歴史的に、組織はセキュリティと使いやすさをトレードオフとして見てきましたが、今日利用可能な新しい ID テクノロジでは、両方を持つことが可能です。

これらの主要なコンポーネントを展開の青写真（ソリューション構成）で組み合わせると、アーキテクチャパターンが展開され、組織全体のアクセス管理のニーズのほとんど（すべてではないにしても）をサポートすることができます。

ブラウザやモバイル・アプリなどのクライアントからDMZを経由して企業ネットワークに入るユーザーのアクセス管理パターンの可能性を示す図。

図11 - アクセス管理パターン

パターンの説明 ブラウザからWebアプリケーションへ ユーザは、認証サービスによって保護されたWebアプリケーションにサインインする必要があります。 ネイティブアプリ（シングルページアプリ）からWeb APIへ ネイティブアプリは、認証サービスによって保護されたWeb APIからリソースにアクセスするために、ユーザーを認証する必要があります。 サーバーアプリケーションから Web API へ Web ユーザーインターフェースを持たないサーバーアプリケーションは、認証サービスで保護された Web API からリソースを取得する必要があります。

アイデンティティの標準

IAMソリューションのアーキテクチャは、適用される標準に対処することなしには完成しません。IAM は事実上すべての企業システムに触れるため、インターフェイスは標準に準拠しなければならず、そうでなければ必要とされるカスタマイズの量を最小限に抑える必要があります。IAMアーキテクチャは、相互接続を容易にし、業界標準に基づいて構築された主要なセキュリティイネーブラーを結びつける「プラグ可能な」アプローチをサポートしなければなりません。IETF、OASIS、Kantara Initiative、OpenID Foundation などの業界団体（標準化団体）があります。

今日の現代的な ID およびアクセス管理をサポートする主要な標準は以下のとおりです。

OIDC、OAuth、SAML のロゴ

図 12 - OIDC、3 OAuth2 4、SAML 5 のロゴ

結論

IAM実務者は、自分が働いている組織内で使用されているエンタープライズ・アーキテクチャーのアプローチを採用すべきである。アーキテクチャーへの企業アプローチがない場合、IAM実務者は、IAMプロジェクトが影響を受ける可能性のあるすべてのビジネスシステム、サポートされるアプリケーションの種類、IAMソリューションが展開されるインフラストラクチャを考慮したアーキテクチャー・アプローチを開発する必要があります。

このようなアプローチを採用したIAMプロジェクトは、スケジュールと予算の制約の中で完成する可能性が格段に高くなります。また、ユーザーを満足させる可能性も高くなります。

著者

アンドリュー・キャメロン

スーツにネクタイを締めた人物がカメラに向かって微笑んでいます 説明は自動的に生成されます アンドリュー・キャメロン氏は、ゼネラルモーターズのアイデンティティおよびアクセス管理のエンタープライズ・アーキテクトです。彼の責任は、同社のIAMテクノロジープラットフォームの戦略と実装ロードマップの定義と、GMのデジタルビジネスを推進している多くのイニシアチブのアーキテクチャの品質を確保することです。

グラハム・ウィリアムソン

スーツを着てネクタイを締めた人が微笑みながらカメラを見ています 説明の自動生成 グラハム・ウィリアムソン氏は、20年以上にわたり、商業および政府機関のIAMコンサルタントとして、アイデンティティ管理とアクセス制御、エンタープライズ・アーキテクチャとサービス指向アーキテクチャ、電子商取引と公開鍵インフラストラクチャ、ICT戦略の開発とプロジェクト管理の専門知識を持つ。香港のキャセイパシフィックやメルボルンのセンシスなどの商業組織、オーストラリアのモナッシュ大学やグリフィス大学などの学術機関、オーストラリアのクイーンズランド州政府CIOオフィスやノーザンテリトリー政府、シンガポールの内務省などの政府機関の主要プロジェクトを担当している。

  1. 読者の方は、IDProのBoK論文「Introduction to Project Management for IAM Projects（IAMプロジェクトのためのプロジェクトマネジメント入門）」が参考になるかもしれません。Williamson, Graham, and Corey Scholefield, “Introduction to Project Management for IAM Projects” IDPro Body of Knowledge, vol 1, issue 1, March 2020, https://bok.idpro.org/article/id/25/ を参照してください。

  2. “SCIM: System for Cross-domain Identity Management” http://www.simplecloud.info/

  3. OpenID Connect、ウェブサイト、OpenID Foundation、https://openid.net/connect/

  4. OAuth2、ウェブサイト、https://oauth.net/2/ .

  5. “Security Assertion Markup Language (SAML) V2.0 Technical Overview” OASIS, http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html .