ID管理システムを本番環境で運用していると一番気を遣うのが、人事システムからわたってくるデータの間違いへの対応です。
ID管理システム自体はデータを生成するわけではないので、人事システムなどの信頼できるデータソースから従業員や組織に関する元情報を受け取り、そのデータをあらかじめ決めたポリシーに従ってActive Directoryやアプリケーションなどへ渡していきます。
つまり、ID管理システムが正しく動作するためにはデータソースから正しいデータがわたってきていることが大前提となっているわけです。
しかし、人事システムもあくまで人が運用しているシステム。社員情報を登録するのも人なわけで、必ず入力ミスは起きますし、データの受け渡しをするインターフェイスにバグが絶対に無いとは誰も言い切れるものではありません。
そのような前提を踏まえてID管理システムを設計～構築する時は、入力データのバリデーションをするための前処理を入れる検討をするなど、色々と気を使います。
その際に、まだ氏名の漢字間違い等であれば、あまり影響はないのですが、役職や組織などアクセス権に関する属性の間違い（これが意外と多いんです！）や、データの欠損を含む在籍状態の間違いなど、非常にインパクトの大きな間違いがしばしば発生するのも事実です。
間違って退職扱いになってしまい、各アプリケーションからIDが消えてしまったりするとリカバリを行うのに非常に大きな手間がかかりますし、特にActive DirectoryではObjectSidでIDを識別しているので、同じ名前でユーザを再作成すればよい、というものではなく大惨事を招いてしまいがちです。
各社のID管理製品は特にこのようなデータ削除に関する保護措置を用意しているものが多く、Microsoft Identity Manager（MIM）においてもあらかじめ設定した閾値を超えたオブジェクトの削除が一気に発生するとジョブを停止する機能「Specify number of deletions to process」が用意されています。
（昔からある機能なので、当然まだForefront Identity Manager（FIM）を使っていてもこの機能は使えます）
早速みてみます。
シナリオとしては、以下を想定してみます。
- ユーザデータをCSVからMIMに取り込んでいる
- 前日までの取り込みで現在MIM上に10,000ユーザが存在している
- 人事システムとのインターフェイスの不備で取り込むCSVの大多数のレコードが消えてしまった
◆入力データ
正しい入力データ（前日のデータ）はこちら。10,000件レコードが存在します
しかし、当日2レコードしかないCSVがわたってきてしまいます。
データ取り込み前まではMIM上に10,000件データが取り込めています。
◆何も考えずにデータを取り込む
インポートすると、当然のことながら9,998件がDelete対象として認識されてしまいます。このままMetaverseへの同期処理を実行すると本気であちこち消えていきます。。。
◆一括削除防止機能を設定する
インポート処理で削除が一定の件数を超えたら処理を止めるための設定を行いますので、CSV取り込み用のConnector SpaceのRun ProfilesのImport処理の中に設定項目が存在します。
Thresholdの項目の中の「Specify number of deletions to process」にチェックを入れて、とりあえず10に設定してみます。
ちなみにこの設定、一度設定～保存しても、再度設定の編集画面を開くと保存した内容が「表示上」はクリアされてしまいます。キャンセルを行えば設定は残るのですが、間違えて保存をすると本当に設定がクリアされてしまうので、注意が必要です。（昔からのバグですね）
◆取り込んでみる
先の間違ったデータを取り込んでみます。
すると、Statusが「stopped-deletion-limit」でジョブが停止しているのがわかります。
削除対象としてマークされた件数も先ほど設定した10件になっていることがわかります。
このようにジョブが異常終了してくれるので、後続で同期ジョブを流す前にConnector Spaceの段階でリカバリができ、大惨事を防ぐことが可能になります。
特に期初の大規模人事異動時などはこのような機能をうまく使って、上手にID運用をしていくとよいと思います。
投稿
