アイデンティティ・インサイトを活用したアイデンティティ・ガバナンス・ソリューションの設計

Identity Access Management(IAM)は誇大広告だけでなく、新しい現象でもありません。アクセス制御アプリケーションは数十年にわたって使用されており、多くの組織のインフラストラクチャに組み込まれていますが、管理がますます難しくなっています。

お客様は、複数のアプリケーションにアクセスできる可能性のある何十万人ものユーザーを管理することがあります。つまり、何十万もの承認が可能な可能性があります。アプリケーション内のアクセス権やアクセス権などの承認。すべて保守が必要です。これにより、誰がどのコンテキスト/条件の下でどの情報にアクセスできるか、およびどのようにアクセスできるかが疑問視されます。

アーキテクチャ

このリファレンス・アーキテクチャでは、次のサービスを利用します。

  • Oracle Identity Governance (OIG)
  • Oracle Identity Role Intelligence (OIRI)
  • Oracle Accessガバナンス(AG)
  • Oracle Access Management (OAM)
  • Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)

このアーキテクチャは、Oracle Cloud Infrastructure (OCI)、顧客データ・センターまたはサードパーティ・クラウドに実装できます。このアーキテクチャを利用するメリットの一部を次に示します。

  • 冗長で時間のかかる手動プロセスを排除することで、ユーザー・アクセスのプロビジョニングの操作コストを削減します。
  • コンテナやマイクロサービスなどの新しいテクノロジーに投資することで、合理的な投資収益率を達成
  • 効果的な制御を導入し、人的エラーを排除することで、セキュリティ・リスクを最小化
  • アクセス・データを1つのビューに統合し、誰がどのエリアにアクセスできるか、またそのアクセスが組織にとってどの程度リスクが高いかについてのインサイトを提供します。このビューでは、セキュリティ所有者とマネージャがユーザー・アクセス・パターンを完全に表示できます。
  • すぐに使える直感的なダッシュボードを活用することで、生産性とエンドユーザーの満足度が向上します。
  • 規制対象のコンプライアンス・レポートを自動化します。

論理アーキテクチャ

次の図は、ターゲットのIAMリファレンス・アーキテクチャを示しています。



アイデンティティ- ガバナンス- 論理-architecture.zip

Oracleプラットフォームによって実装される各コンポーネントの機能は次のとおりです。

Oracle Identity Governance (OIG)Oracle Identity Role Intelligence (OIRI)およびOIGコネクタには、次のものがあります。

  • 管理

    ユーザー・アイデンティティを管理するためのセルフサービス機能および委任管理機能(ユーザーおよび特権アカウントを含む)。

  • プロビジョニング

    中央管理ポイントからターゲット・システムへのユーザー情報の外部フロー。すべての管理対象リソースに対するアカウント、ロールおよび権限のすべてのアクション(作成、更新、削除など)を追跡します。

  • リコンシリエーション

    信頼できるシステムまたはターゲット・システムからのユーザー情報の内部フロー。通常、ユーザー情報には、アカウント、ロール、および中央管理プラットフォームへの権限のすべてのアクション(作成、更新、削除など)が含まれます。

  • ワークフロー管理

    リソース・アクセス・リクエストを管理するために、ポリシーベースの自動プロビジョニングおよび承認プロセスのモデリングを可能にする、ビジネスおよびITプロセスを自動化する機能。

  • パスワード管理

    パスワードのリセットおよび変更に対するパスワード・ポリシー・サポートおよびセルフサービス管理。

  • 通知

    エンドユーザー向けおよび関連するユニットの管理、システム、セキュリティ、委任管理者向けプラットフォームで処理されるすべてのタイプのイベントに関する情報のルーティング。

  • コネクタ

    様々な異種アイデンティティ対応ITシステムへの3層統合機能。この3層の機能は、最小限のカスタム開発、最大限のコード再利用、およびデプロイメント時間の短縮を目的としています。

  • ルール・エンジン

    ユーザー、ロール、資格、アカウントおよび組織管理に関連するプロセスの実行の評価基準を定義します。

  • 職務の分離

    IDA(アイデンティティ監査)を使用して、違反を定義および検出します。IDAの検出メカニズムは、リソースへのユーザーの実際のアクセスを継続的に監視して違反を検知する検知メカニズムを備えています。IDAには、探偵と予防の2つのモードがあります。

  • 委任された役割およびアクセス管理

    アクセス権の割当、リソースの自動プロビジョニング、または承認やアクセス認証などの共通タスクで使用できるユーザーの論理的なグループ。

  • リスクの分析

    高、中、低リスクのレベルをロール、アカウント、および資格に直接割り当てることができるすべての重要な機能に対する包括的なリスク管理機能。

  • ロール・インテリジェンスおよびマイニング(OIRI)

    ピア・グループ間の権限パターンの検出。ユーザー属性に基づくロール・マイニングのトップダウン・アプローチがサポートされています。アプリケーションと権限、またはハイブリッド・トップダウン・ボトムアップ・アプローチに基づいてデータをフィルタするボトムアップ・アプローチ。

    既存のロールを持つ候補者ロールの比較により、ロールが急増しないようにします。ユーザー・アフィニティおよびロール・アフィニティに基づいて候補ロールを微調整する機能。ロールを採用するワークフローをトリガーするOIGへのロールの自動発行。OIGデータベースやフラット・ファイルなど、様々なソースからデータをマージし、候補ロールを本番に移行する前にWhat-If分析を提供する機能。

Access Governance (AG)およびAGエージェントには、次のものがあります。

  • 直感的なユーザー・エクスペリエンスで認定キャンペーンを実施し、適切かつタイムリーなアクセス・レビューを確保します。インテリジェント・ワークフローは、ユーザーをガイドし、簡単な提案を行い、コンプライアンスと規制目標の達成を迅速化します。
  • 機械学習ベースのインサイトのリスク・スコアリングと高度な分析を規範的な推奨事項とともに使用して、リスク意識の向上、手動の認定作業の削減、アクセス制御/プロビジョニングの自動化を実現します。
  • グループ・アクセス・データを1つのビューに統合し、誰が何にアクセスできるか、またそのアクセスが組織にとってどの程度リスクが高いかの詳細を示します。
  • Oracle Identity Governanceから直接権限データを取得し、修正をトリガーするアイデンティティ・データ・オーケストレーション。

Oracle Access Manager (OAM)およびOAM WebGateには、次のものがあります。

  • (ソリューション・インタフェースのアイデンティティ、属性、ロール、ルールおよび権限に基づいて)リアルタイムのアクセス・ポリシー決定および強制を含む認可。
  • Active Directory/Azure Active Directoryユーザー・リポジトリに対する、ソリューション・インタフェースのリクエストされたアイデンティティのリアルタイム検証を使用した認証。
  • フェデレーテッド・シングル・サインオン。ソリューション・インタフェースのサービス・プロバイダのロールにおけるOCI IAMのアイデンティティ・プロバイダの役割。
OCI IAMには、次のものがあります。
  • OAMとのフェデレーテッドSSO(サービス・プロバイダとして、OAMがアイデンティティ・プロバイダとして機能)。

ターゲット・アプリケーション

実装する統合ターゲット・アプリケーションには、次のものがあります。

  • Identity Reconciliation: Peoplesoft、SAP HRMS、Oracle e-Business Suite HRMS
  • プロビジョニングおよびターゲット・リコンシリエーション: SAP、Siebel、Salesforce、ServiceNow、Oracle e-Business Suite、Microsoft Office 365、Azure Active Directory、Amazon Web Services。

物理トポロジ

次の図は、複数の可用性ドメインを含むOracle Cloud Infrastructureリージョン内のKubernetesクラスタのリファレンス・アーキテクチャを示しています。複数のアベイラビリティ・ドメイン(データ・センター)を利用しながらレイテンシとパフォーマンスの低下を最小限に抑えるため、同じリージョン内のディザスタ・リカバリ戦略をお薦めします。提案されたトポロジでは、3つの可用性ドメインのうち2つが利用されます。これは、すべてのポッドが同じ可用性ドメインのワーカー・ノードで実行されることが推奨されるためです。ディザスタ・リカバリ戦略の詳細は、次のとおりです。



アイデンティティ・ガバナンス-topology.zip

このアーキテクチャには、次のコンポーネントがあります。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用するとネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • リージョン

    Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイは、VCN内のパブリック・サブネットとパブリック・インターネット間のトラフィックを許可します。

  • Webアプリケーション・ファイアウォール(WAF)

    Oracle Cloud Infrastructure Web Application Firewall (WAF)は、ロード・バランサやWebアプリケーション・ドメイン名などの強制ポイントにアタッチされている、PCI (Payment Card Industry)準拠のリージョンベースおよびエッジ強制サービスです。WAFは、悪意のある不要なインターネット・トラフィックからアプリケーションを保護します。WAFは、インターネット接続エンドポイントを保護することで、顧客のアプリケーションに対する一貫性のあるルール適用を実現できます。

  • 動的ルーティング・ゲートウェイ(DRG)

    DRGは、VCNとリージョン外のネットワーク(別のOracle Cloud Infrastructureリージョン内のVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)の間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。

  • サービス・ゲートウェイ

    サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

  • ネットワークアドレス変換(NAT)ゲートウェイ

    NATゲートウェイを使用すると、VCN内のプライベート・リソースは、受信インターネット接続にこれらのリソースを公開することなく、インターネット上のホストにアクセスできます。

  • サブネット
    このアーキテクチャのVCNは、本番環境とディザスタ・リカバリ環境をペアにした10個のサブネットで構成されます。すべてのサブネットは可用性ドメイン固有です。つまり、レイテンシとパフォーマンスの低下を最小限に抑えるために、1つのデータ・センター内で制限されます。同じVCNおよびリージョンにデプロイされたディザスタ・リカバリによって、可用性ドメイン障害から保護されます。
    • 2つのパブリック・サブネットがWeb層用です。
    • プライベート・ロード・バランサの2つのプライベート・サブネット。
    • 2つのプライベート・サブネットは、KubernetesクラスタおよびKubernetesクラスタのノードを管理するために必要なツールを含む管理ホスト用です。
    • 2つのプライベート・サブネットは、KubernetesクラスタAPIエンドポイント用です。
    • 2つのプライベート・サブネットは、指定されたプライベート・ネットワーク(VCN)からの接続のみを許可するAutonomous Databaseプライベート・エンドポイント・アクセス用です。
  • Load Balancerのノード
    • 1つのリージョン別パブリック・ロード・バランサ・ノードは、本番環境とディザスタ・リカバリ環境で、ソリューションのWeb層を実行しているコンピュート・インスタンスにトラフィックをインターセプトして分散します。
    • 環境ごとに1つの可用性ドメイン固有のプライベート・ロード・バランサ・ノードが、コンテナ化されたアプリケーション中間層を実行しているKubernetesノードにトラフィックをインターセプトして分散します。
  • Kubernetesワーカー・ノード

    Kubernetesワーカー・ノードは、コンテナ化されたアプリケーションがデプロイされるコンピュート・インスタンスです。このリファレンス・アーキテクチャのすべてのワーカー・ノードは、単一のノード・プールにあり、プライベート・サブネットにアタッチされています。必要に応じて、複数のノード・プールを作成できます。

    このリファレンス・アーキテクチャのワーカー・ノードには、パブリック・インターネットから直接アクセスできません。コンテナ化されたアプリケーションのユーザーは、ロード・バランサを介してそれらにアクセスできます。管理者は、要塞サービスを介してワーカー・ノードにアクセスできます。Kubernetesマスター・ノードはOracleのテナンシで実行され、表示されません。

  • Kubernetes APIエンドポイント

    専用サブネットでホストされているクラスタ・コントロール・パネルのKubernetes APIエンドポイントを使用すると、エンド・ユーザーはKubernetesリソース(ポッド、ネームスペース、構成マップ、イベントなど)を問い合せて操作できます。

  • ポッド/サービス・オーバーレイ・ネットワーク

    Kubernetesネットワーキング・モデルは、ポッドにクラスタ内で一意のルーティング可能なIPアドレスがあることを前提としています。Kubernetesネットワーキング・モデルでは、ポッドはこれらのIPアドレスを使用して相互に通信します。クラスタのコントロール・プレーン・ノードと、他のクラスタ、他のサービス(ストレージ・サービスなど)およびインターネット上のポッド。

  • プライベート・エンドポイントのあるAutonomous Database

    データベース・プロパティを設定して、ターゲット・ホストへのすべての送信接続がプライベート・エンドポイントのエグレス・ルールの対象となり、それによって制限されるようにすることで、セキュリティを強化します。エグレス・ルールは、VCNセキュリティ・リスト、またはAutonomous Databaseインスタンスのプライベート・エンドポイントに関連付けられたネットワーク・セキュリティ・グループ(NSG)で定義されます。

  • 要塞サービス

    Oracle Cloud Infrastructure (OCI) Bastionは、パブリック・エンドポイントがなく、ベア・メタルや仮想マシン、Oracle MySQL Database ServiceAutonomous Transaction Processing (ATP)、Oracle Cloud Infrastructure Kubernetes Engine (OKE)、およびSecure Shell Protocol (SSH)アクセスを許可するその他のリソースなど、厳密なリソース・アクセス制御を必要とするリソースへの制限付きで時間制限のあるセキュアなアクセスを提供します。OCI Bastionサービスを使用すると、ジャンプ・ホストをデプロイおよびメンテナンスせずにプライベート・ホストへのアクセスを有効にできます。さらに、アイデンティティベースの権限と一元化された監査済みの期限付きSSHセッションにより、セキュリティ・ポスチャが向上します。OCI Bastionは、要塞アクセスのパブリックIPの必要性をなくし、リモート・アクセスを提供する際の手間と潜在的な攻撃対象領域を排除します。

  • 永続記憶域レプリケーション

    NFSでのRsyncは、メンテナンスと構成を最小限に抑えながら、ドメイン構成をレプリケートする永続ストレージ・レプリケーションの方法を提供します。

  • Autonomous Data Guard (Data Guardレプリケーション)

    現在のリージョンのスタンバイ・データベースでAutonomous Data Guardを有効にした場合、Autonomous Databaseはプライマリ・データベースをモニターし、プライマリ・データベースが停止すると、スタンバイ・インスタンスが自動的にプライマリ・インスタンスのロールを引き継ぎます。ローカル・スタンバイ・データベースでAutonomous Data Guardが有効になっている場合、Autonomous Databaseは、プライマリ・データベースの状態に応じて、次のことが可能な同一のスタンバイ・データベースを提供します

    プライマリ・データベースが停止すると、Autonomous Data Guardは最小限の中断でスタンバイ・データベースをプライマリ・データベースに変換します。フェイルオーバーが完了すると、Autonomous Data Guardによって新しいスタンバイ・データベースが作成されます。

    スイッチオーバー操作を実行できます。この場合、プライマリ・データベースがスタンバイ・データベースになり、スタンバイ・データベースがプライマリ・データベースになります。

考慮事項

アイデンティティ・ガバナンス・ソリューションを設計する場合は、次の点を考慮してください。

ディザスタ・リカバリ

OCI上のディザスタ・リカバリ・ソリューションは、アクティブ/パッシブ・モデルです。

Oracle Cloud Infrastructure Kubernetes Engine上のOracle WebLogic Domain(WLS)、Oracle Identity and Access Management(OIGおよびOAM)、ロード・バランサ、Oracle Autonomous Transaction Processing(ATP)、および1つの可用性ドメイン(AD)内の2つのOracle HTTP Server(OHS)で構成されるプライマリ・システムがあります。

セカンダリ・システムは、同じアーキテクチャ・コンポーネントで構成されていますが、可用性ドメインは異なります。アベイラビリティ・ドメイン、データ・センターおよびサイトは、災害発生時にコンポーネントを保護するために、プライマリ・アベイラビリティ・ドメインから十分に物理的に配置されます。

詳細の参照

アイデンティティ・ガバナンス・ソリューションの設計についてさらに学習します。

次の追加リソースを確認します。

確認

著者: Katerina Kalimeri

貢献者: Andreas Theodoridis、Ioannis Episkopakis、Kostantinos Pateras

変更ログ

このログには、重要な変更が一覧表示されます。