退職者が機密データを見れる状態じゃない？ midPointによる「アクセス認定」で定期的な権限の棚卸し：midPointで学ぶIDガバナンス＆管理（IGA）の基礎（6）

「IDガバナンス＆管理」（IGA）についてOSS「midPoint」を利用したハンズオンで学ぶ連載。今回は、「アクセス認定」による定期的な権限の棚卸しについてです。

[佐藤高志，野村総合研究所]

　オープンソースソフトウェア（OSS）でありながら「IDガバナンス＆管理」（Identity Governance and Administration：IGA）機能を備えた「midPoint」を使って、ハンズオン的にIGAについて学ぶ本連載『midPointで学ぶ「IDガバナンス＆管理」（IGA）の基礎』。

　前回の第5回は自動化が難しい権限付与のユースケースに対するワークフローを使ったアクセス要求／承認を行いました。今回は、付与した権限を定期的に棚卸しする「アクセス認定」を紹介します。

midPointにおける棚卸しの考え方

　連載第3回では人事システムなどの信頼できる源泉情報を使用した「IDライフサイクル管理」「フルフィルメント」、第4回は同じく源泉情報に基づいた「エンタイトルメント管理」を紹介しました。これらにおいては、ユーザーの削除や権限の剥奪がシステムによって自動化されるので、常にシステムが適切な状況に保たれます。

　一方で、第5回のような人手を介した権限付与においては、権限付与時こそ承認者によって適切に判断されるものの、その後、退職や異動などのイベントで権限が不要になった場合でも、そのイベントを契機として人手によって判断されず、権限が残り続ける不適切な状況となってしまいがちです。

　そこで、定期的に権限付与が適切なのかどうかを確認する必要があります。midPointはこの考え方に基づき「アクセス認定」機能を提供しています。これは、管理者などに対して現在のアクセス権限付与状況が正しいかを定期的に確認させる機能です。

　midPointでは、「キャンペーン」を定義してアクセス認定を実施します。キャンペーンは次のリストを設定したものです。

• スコープ定義：何を棚卸しするのか。例えば、「ユーザーに対するロールのアサインを棚卸しするのか」「組織に対するロールのアサインも棚卸しするのか」など
• ステージ定義：スコープに対する棚卸しの各段階を「ステージ」という。それぞれのステージで棚卸しする「レビュアー」などを設定する

　スコープ定義での棚卸し対象や、ステージ定義でのレビュアーの選択は、柔軟に設定できます。

　アクセス認定の流れは下図の通りです。

※ステージは複数個定義可能

Example社における権限棚卸しシナリオ

　第5回では、運用2課の一般社員が開発アプリケーションロールを申請し、サービス開発部の部長が承認することで、開発ツール（PostgreSQL）のアクセス権限が付与されるシナリオでした。

　具体的には、下表のような登場人物でした。

シナリオ	従業員番号	氏名	所属	役職
申請者	023	渡辺英輔	運用2課（1320）	一般社員
承認者	001	安藤ありす	サービス開発部（1200）	部長

　今回のハンズオンでは、プロジェクトが終了して手動付与した権限が不要になった後、サービス開発部部長の安藤ありすさんがアクセス認定機能で、渡辺英輔さんに手動付与した権限を棚卸し（権限剥奪）するシナリオにします。

　midPointでは、アクセス認定の権限を持つ人物を「レビュアー」というので、まず安藤さんを承認者兼レビュアーに設定します。その後システム管理者がキャンペーン定義を設定し、キャンペーンを開始し、安藤さんがキャンペーンを実施します。

事前準備

　ここからはハンズオンを実施します。まずは事前準備です。

ハンズオンの前提環境

　本手順は第5回までで構築および設定した環境を前提としています。まだ環境を構築していない場合はリポジトリから次のように取得してください。

$ cd midpoint-sample-configuration
$ git pull

　特に今回のシナリオでは、次の3つが必要になるので、設定されているかどうかを確認してください。

• ユーザー023（渡辺英輔）に「Development Application Role」ロールが付与されていること
• ユーザー001（安藤ありす）に「Approver」ロールと「End User」ロールが付与されていること
• ユーザー001（安藤ありす）に「Development Application Role」ロールが「承認者」として付与されていること

承認者の設定

　midPointのアクセス認定では、「レビュアー」がロールの付与状況を確認し、棚卸しを判断します。「誰をレビュアーにするのか」は後で細かく設定しますが、まずレビュアーになるための大前提として、「Reviewer」ロールが必要です。Reviewerロールがないとアクセス認定機能の画面を利用できないので、例えレビュアーに設定されても、棚卸しできません。

　まずは、承認者の安藤さんに、Reviewerロールを付与します。midPointに「administrator」でログインし、midPointの管理画面から「ユーザー」→「すべてのユーザー」を選択し、「001」を選択します。「アサイン」→「ロール」を選択し、「新規」ボタンを押します。「Reviewer」を選択し、「追加」ボタンを押します。

　「Approver」「Development Application Role」（承認者）、「Development Manager Role」「End User」の4つが既に付与されており、新たにReviewerのロールが付与されることを確認し、「保存」ボタンを押します。

　これで承認者の設定は完了です。

キャンペーン定義の設定

　次に、「キャンペーン」を定義します。今回設定するキャンペーンは下記リンクに格納されています。

• https://github.com/Hitachi/midpoint-sample-configuration/blob/main/campaigns/chapter-6/campaign.xml

　midPoint管理画面の「オブジェクトのインポート」から「ファイルの選択」を押し、「campaign.xml」を選択して「オブジェクトのインポート」を押してください。

　「アクセス認定」→「キャンペーン定義」で今回登録されたキャンペーンを確認できます。表示された一覧の中から、「月次棚卸し」を押してください。

　簡単に、設定内容を説明します。基本情報タブでは、主に次の項目が設定されています。

• ステージの結果から全体的な結果を導き出すためのストラテジー：「各ステージの結果をどうまとめてキャンペーンの結果とするか」を設定する。今回のステージは1個のみなので、どの設定でも大きな影響はない
• 修復：キャンペーン終了後、権限剥奪を自動化するか、報告にとどめるかの設定。今回は自動的な剥奪を設定する

　「スコープ定義」タブでは、「何を棚卸しするか」を定義しています。今回は「ユーザーへのロールの付与を対象とする設定」としています。フィルター設定で複雑な条件を設定することも可能です。

　ステージ定義では、「レビュアーは誰か」「複数のレビュアーの判断が分かれた場合にどうするか」などを設定します。今回は、「ロールの承認者」をレビュアーとする設定としています。これは、前回のロール要求での承認者と同じです。

キャンペーン実施

　ここからはキャンペーンを実施します。

キャンペーンの開始

　administratorでログインしていない場合はログインしてください。midPointの管理画面から「キャンペーン」→「キャンペーン定義」を選択し、「月次棚卸し」の右側にある「キャンペーンの開始」ボタンを押します。キャンペーン定義からキャンペーンが作成されます。

　次に、作成されたキャンペーンを開始します。管理画面メニューの「キャンペーン」→「キャンペーン」を選択すると、作成されたキャンペーンが一覧表示されます。

　「月次棚卸し 1」の右にある「キャンペーンの開始」ボタンを押すと、状態が「レビュー・ステージ中」になり、レビュアーによる棚卸しが可能になります。

レビュアーによる棚卸し

　この状態で、administratorを画面右上からログアウトし、承認者のユーザー001でログインしてください。ログイン画面でユーザー名「001」、パスワード「qwe123」を入力します。

　ログインすると、メニューのアクセス認定に数字の「1」が付いています。

　もしアクセス認定メニュー自体が表示されない場合は、ユーザー001にApproverロールが付与されているかどうかを確認してください。

　メニューの「アクセス認定」→「私の作業アイテム」を選択すると、レビューするべき対象の一覧が表示されます。今回は第5回で付与した渡辺さん（023）へのDevelopment Application Roleが表示されているはずです。

　右側の「承認」などのボタンは、この権限付与に対して判断するボタンです。それぞれの意味は次の通りです。

• 承認： この権限付与を引き続き承認する
• 取り消し：この権限付与は望ましくないので、キャンペーン終了後直ちに取り消す
• 削減：この権限付与は望ましくないが、単純に取り消すのも望ましくなく、例えば関係者内での議論の対象としたいことなどを表す。デフォルト設定では、キャンペーン終了後も権限付与は継続する
• 未定：判断が付かないことを表す
• 応答なし：まだ判断をしていないことを明示したい場合に押す

　これら全ての状態が不要の場合は、システム設定で変更できます。例えば、「承認」と「取り消し」だけにすることが可能です。

　今回は、渡辺さん（023）が既にプロジェクトを離任していると想定し、「取り消し」を押します。すると表示が消えてしまいますが、右上の「“応答なし”の場合のみ参照」のチェックボックスをオフにすると、再度表示され、判断を変更できます。

キャンペーンの終了と結果確認

　ステージの期間（今回は1日）が経過するとステージが終了しますが、今回はハンズオンなので、強制的にステージを終了して次に進めます。administratorでログインし直し、管理画面の「アクセス認定」→「キャンペーン」を選択します。

　右側に表示される「ステージをクローズ」ボタンを押すと「修復の開始」ボタンが表示されます。これも押すと、次のような画面に遷移します。

　これは、今回のキャンペーンの結果をバックグラウンドでシステムに反映する処理が開始されたことを表しています。今回は対象が1件のみなので、この表示を見たころには完了しているはずです。

　ロールが剥奪されていることを確認します。「ユーザー」→「すべてのユーザー」を押し、「ユーザー一覧」の2ページ目のユーザー名「023」を押します。「アサイン→ロール」を選択してEnd userのみが表示されていれば、成功です。

監査ログによる確認

　今回のアクセス認定（権限の剥奪）を、監査ログで確認します。管理画面の「レポート」→「監査ログビューアー」を選択します。これまでの操作の監査ログが表示されます。

　ここで、赤枠で囲った行に注目します。これは、イニシエーターが001、つまり先ほどレビュアーが権限の剥奪を指定したログです。内容を見るには、「日時」を押します。

　「変更 アクセス認定キャンペーンのアクセス」を開くと、この例では「case/[5]/workItem/[1]/output」の「outcome」が「http://midpoint.evolveum.com/xml/ns/public/model/certification/outcome#revoke」、つまり「取り消し」に設定されたことが分かります。

キャンペーンの自動実施の設定：タスクの追加

　ここまでのキャンペーンのハンズオンでは、手動でキャンペーンを開始しました。キャンペーンを定期的に自動化するには、キャンペーンを開始する「タスク」の追加が必要です。

　下記リンクに格納されている「タスク定義」を使います。

• https://github.com/Hitachi/midpoint-sample-configuration/blob/main/tasks/chapter-6/create-campaign.xml

　midPoint管理画面の「オブジェクトのインポート」から「ファイルの選択」を押して「campaignTask.xml」を選択し、「オブジェクトのインポート」ボタンを押してください。

　追加できたことを確認するには、管理画面の「サーバー・タスク」→「アクセス認定関連タスク」を選択します。既にキャンペーン後の場合、名前が「Closing」や「Remediation for」で始まる、ステータスが「終了」のタスクも表示されると思いますが、今回チェックするのは名前が「月次棚卸し起動タスク」のものです。

　毎月1日にmidPointのスケジューラによってこのタスクが起動します。このタスクは、キャンペーン定義からキャンペーンを自動的に作成し、開始します。タスクが動いた場合の挙動を確かめるには、該当タスクの行の右側にある「今すぐ実行」ボタンを押すことで、直ちにタスクを起動できます。

まとめ

　今回は、midPointのアクセス認定機能による権限の棚卸しを紹介しました。次回はこれまでと打って変わって、midPointの高度なユースケースの対応例や、今後のロードマップと展望を解説します。