IBM TechXchange Japan Identity and Access Management (IAM) User Group

IBM TechXchange Japan Identity and Access Management (IAM) User Group

 View Only

IBM Verify Identity Governance 11 の以前のバージョンからの変更点の概要

By TOMOHIRO OGAWA posted 15 hours ago

  

こんにちは。

2024年にリリースした、IBM Verify Identity Governance 11 は、以前の IBM Security Verify Governance 10 から変更された点がいくつかあります。

今回は、その変更点の概要をお伝えします。

前提ミドルウェアの変更 (ソフトウェアスタック

IBM Verify Identity Governance の稼働前提のミドルウェアに変更がありました。以下のマニュアルに記載がありますが、ここでは概要をお伝えします。

IBM Verify Identity Governance マニュアル - 技術概要

https://www.ibm.com/docs/ja/sig-and-i/11.0.0?topic=overview-technical#vaoverview__title__3

WebSphere Application Server の変更

Verify Identity Governance の稼働前提であった WebSphere Application Server が、Traditional WAS から WAS Liberty に変わりました。

MQの追加

IBM MQ が前提ミドルウェアに追加されました。JMSという観点で、MQを利用します。

データベースの選択肢追加 (Db2 か PostgreSQL を選択可能)

プロビジョニングのスケジュール情報、履歴等を保持していたデータベースが、Db2 と PostgreSQL のどちらかを利用できるようになりました。

IBM Security Verify Governance ではDb2だけでPostgreSQLは選択できませんでした。

機能の提供箇所の変更

IBM Verify Identity Governance の機能のうち、Compliance で提供している機能である 「ビジネス・アクティビティー」や「リスク」の設定の機能が、Identity Manager 側のコンポーネントで実現できるようになりました。詳しくは、これにより、「ビジネス・アクティビティー」を使った「リスク」の管理、「キャンペーン」といった機能が、従来の Identity Manager 側の管理コンソールで、まとめて利用することができるようになっています。なお、従来のIdentity Manager 側で提供をしていた「再認証ポリシー」や「職務分離ポリシー」は引き続き利用できます。

なお、「ビジネス・アクティビティー」と従来からある「アクティビティー」とは用語は似ていますが異なる機能です。

これらの機能については、以下のブログも合わせてごらんください。

IBM Verify Identity Governanceが活用できるユースケースについて(1/2)

IBM Verify Identity Governanceが活用できるユースケースについて(2/2)

ビジネス・アクティビティー、リスクの設定方法

新たに管理コンソールから利用できるようになった、ビジネス・アクティビティー、リスク は、以下のように設定をします。

  • IVIGでサービス(管理対象システム)を登録します。

  • サービスに対して調整を実行し、管理対象上のグループの情報等を取得します。

  • 取得したグループの情報を「アクセス」として定義します。

  • 「ビジネス・アクティビティー」を定義し「アクセス」と関連付けします。

  • 「リスク」を定義し、「ビジネス・アクティビティー」と「リスク」を関連付けします。

ビジネス・アクティビティー、リスクの活用イメージ

例えば、顧客データを更新できる、会計データを更新できるなど、業務上必要な権限ではあるが、誰がその権限を使えるのか適切に管理をしなければならないような権限が、誰に割り当てられているかをリスクとして把握することができます。

また、インフラの管理者であり、かつ、特権アクセス管理システムの管理者でもある等、複数のシステムで特権を持っていて、不正ができてしまう状態であるなど、従来では見落としがちであった職務分掌リスクも、管理をすることができるようになっています。

これにより、「顧客データの更新ができる」からリスクがある。「経費の申請」と「経費の承認」ができるからリスクがある。「インフラの管理者」であり「特権アクセス管理の管理者」であるからリスクがあるなど、従来よりも理解しやすい状態で、リスクを把握することができる機能を、利用できるようになりました。

従来も「職務分離ポリシー」はロールベースでの制限でありトップダウン的なアプローチでした。これに対し、管理対象システムでの設定値から権限を収集し、そこから関連付けされたビジネス・アクティビティー、リスクを使って判定することができるようになっています。

0 comments
5 views

Permalink