DIY IDM
この記事は https://docs.evolveum.com/iam/myths/diy-idm/ の翻訳です。
アイデンティティ管理 (IDM) は rocket science ではありません。 プロビジョニングの部分は簡単です。 情報をあちこちへコピーするだけです。 単純なスクリプトで簡単にできます。 優れたシステムエンジニア やプログラマー なら、数時間でプロビジョニングシステムを作れます。 単純で、簡単で、安価です。
Joe "Perl" Random, システム管理者
アイデンティティ管理への Do-It-Yourself 方法は、特に熟練したシステム管理者には良い考え方に見えるかもしれません。 しかし現実はかなり違います。 それは単純ではなく、簡単とはほど遠く、安価からも遠く離れています。 アイデンティティ管理に関しては、DIY は良い考え方ではありません。
スクリプトの物語
はい、一度だけ実行してデータをコピーする単純なスクリプトを作るのは簡単です。
システム管理者は毎日それを行っています。
しかし、定期的に実行してデータを更新するスクリプトを作るのは、はるかに難しくなります。
このスクリプトは、target アカウントを作成する前に、それがすでに存在するかどうかを確認しなければなりません。そうしなければ log は常に誤りメッセージで埋まります。
既存アカウントを変更する必要があるかどうかも比較しなければなりません。
パスワードは通常、互換性のない hashing 機構のため比較できないので、それにも対処しなければなりません。
administrator や root のようなアカウントの 例外リスト も必要です。
スクリプトが扱わなければならないケースの数は非常に速く増えます。
そして通常、それらは苦労して発見されます。スクリプトがデータの半分を壊した後で初めて、何をすべきだったかが分かるのです。
コードの size は増えていきます。
読みにくく、保守が難しくなります。
常に壊れ、頻繁な 再テスト が必要になります。
非常に高価になります。
このスクリプトを保守するより、すべてを手作業で行う方が安くなることさえあります。
ロールとポリシー
Do-It-Yourself 方法にとって本当の難所は、セキュリティポリシー全般、特にロールです。 ロールベースのアクセス制御 (RBAC) の原則は非常に簡単に見えます。 実際に簡単です。 問題は、伝統的な単純な静的 RBAC では十分ではないことです。 それは ロール爆発 につながります。 改善する方法はあります。しかしここで、それは静的でも単純でもなくなります。 階層的ロール、ロール内の動的式、parametric ロール、時間 constraint、有効開始 から 有効終了 まで、といったものが必要になります。 これを実装するには何年もかかります。 私たちはそれをよく知っています。 私たちはそれを実装してきました。
別の道もあります。 ロールはまったく不要かもしれません。 そこには流行りの ABAC buzzword があります。 Attribute-Based アクセス制御は、よくできた elegant な考え方です。 しかし問題は、それがプロビジョニングではなく アクセス制御 のために設計されていることです。 プロビジョニングシステムは、実際のアクセスが発生するずっと前にアクセス制御指示 を事前設定しなければなりません。 一方 ABAC は、プロビジョニングシナリオではまだ利用できない多くの "contextual" 属性に依存しています。 したがってプロビジョニングにおける ABAC の価値は非常に限定的です。
ただし、ABAC の原則だけを使うことはできます。ロールの代わりにアルゴリズム、たとえばスクリプトを使ってアクセス権限を決定するというものです。 これは単純なシステムではうまく機能します。 しかし複雑シナリオでは、コードが非常に複雑になります。 つまり、極端に 複雑になります。 多くの if-then-else 文を持つ数万行のコードを想像してください。 Programmer は これをよく知っており、避けるよう教えられています。 それには十分な理由があります。 そのようなコードは保守不能です。 災害です。
ネットワーク
プロビジョニングにはこれだけの複雑性がありますが、それでも比較的単純なソリューションであれば DIY ソリューションを作成し、維持することは可能かもしれません。 これは特に小規模な telco やサービスプロバイダーには魅力的です。 ほぼすべてのアイデンティティは同じで、アクセス制御ルールは単純で、頻繁には変わりません。 しかし、そのようなソリューションの最大の敵は、それを支えるものそのもの、つまりネットワークです。 ネットワークは信頼できるではありません。 Communication 誤りや タイムアウト は常に発生します。 アイデンティティの数が少ない場合、これは通常問題ではありません。 月に1回起きる程度の occasional 問題なら、手作業で簡単に直せます。 しかしアイデンティティの数が増えると、すべてが変わります。 毎日誤りがあるなら、それを手作業で処理することは現実的ではありません。 システム管理労力は増えます。 しかしこれは氷山の一角にすぎません。 そのような誤りは、顧客がサービスにアクセスできない、またはアクセスすべきでない誰かがアクセスを持っていることを意味します。 巻き添え被害 は甚大です。 したがってスクリプトはすべての誤りを適切に扱えるよう設計されていなければなりません。 これは簡単に聞こえるかもしれませんが、そうではありません。 Handling が必要なケースの数は非常に速く増殖します。 スクリプト library はエラー処理 が慢性的に苦手です。 自分の スクリプト言語の文書 を調べて、"already exist" エラーと タイムアウト をどう区別するか考えてみてください。 これは当然です。スクリプト言語は quick prototyping のために設計されています。 厳密なエラー処理 と 回復 のために設計されているわけではありません。 そして、そのようなシナリオをどう テスト するのか考えてみてください。 そして re-test。 さらに re-test。 すべての変更の後にです。
解決策
DIY は良い start です。 非常に単純で非常に静的なシナリオでは機能します。 しかしスクリプトが100行を超えるようになったら、別の方法を考える時です。 アイデンティティ管理システムを手に入れてください。 それは大きく高価なシステムである必要はありません。 選択できる優れた open-source システムがいくつかあります。 オープンソースシステムには、自分の正確必要性に合わせてカスタマイズできるという追加の advantage があります。
アイデンティティ管理ソリューションを開発する時間があるなら、scratch から始めないでください。 それに必要な作業の量は膨大です。 少なくとも、現在想定している10倍以上です。 完成させることはできず、作業は無駄になる可能性が非常に高いです。 既存 オープンソース プロジェクトを見つけ、力を合わせてください。 既存コード base から大きな効果を得られ、すばやく開始できます。 そしていつでもコードを変更して自分の必要性に合わせてカスタマイズでき、その変更をコミュニティに contribute できます。