IdMを実装します。 パート3.1。 IdMが必要であることは明らかです-次は何ですか？ 目標、タスク、利害関係者

一連の記事の前の部分で 、IdMが必要かどうか（つまり、アクセス制御）と、IdMソリューションを実装する価値があるかどうかを判断する方法について説明しました。 少なくとも、この問題について考えていることを示す兆候は何であるかを判断しました。 次は？

IdMのトピックを始めるには、いくつかの重要な決定事項があります。

1. 目標と目的。 利害関係者。
2. 従業員にアクセス制御システムを実装する際に使用するアプローチとプラクティス、導入する手順とプロセス、必要な操作を企業のビジネス活動に統合する方法
3. 使用する技術的ソリューション（ドメインポリシーから始まり、IdMソリューションで終わる）および必要な機能を決定する方法
4. 技術的な解決策の対象者
5. 予算を策定し、正当化する方法は？ （これは最も興味深く、燃えているトピックです）
6. 経営陣へのプレゼンテーション。
7. プロジェクトを開始するときに考慮すべきことは何ですか？

それでは、ポイントを見ていきましょう。

1.目標と目的。 利害関係者。

IdMが何かをしなければならないことが明らかになったとします 。 いったい何？ 実装する機能 どのポリシーを導入および制御しますか？ そして、このトピックでの作業から何を期待しますか：プロセスの整理、管理の確立、監査の実施？ それとも自動化が必要ですか？

頭に浮かぶ最初の答え-IdMはあなたの会社で需要があるものでなければなりません。

ITIL、Cobit、ISO / IEC 2700xなど、一般的な標準、知識のコード、および一般に受け入れられている慣行は、すべての人に簡単な真実を伝えるために一生懸命努力しています：ミッション、戦略、文化に合った特定の企業に適したもののみを実装する必要がありますおよび組織構造。 次のような特定のビジネスに対する実装された各サービスおよびシステムの影響を考慮する必要があります。

• ユーザーの利便性 （この場合は内部）とビジネス継続性。 （多くの場合、これらは密接にリンクされた概念です：銀行のオペレーターがひどいインターフェースと不適切な機能のために支払いをほとんどできない場合、何人の顧客がキューから吐き出して別の銀行に出ますか？）
• 金融要素 （サービスは負担になりません）。
• システムの信頼性 （1か月あたり1時間以下のシステムダウンタイムの可能性があるSLAは、一部のシステムで非常に人気があります）。
• 情報セキュリティのレベルは十分でなければなりません 。 すなわち 「試してみるだけで」ペストリー販売会社でSOCを構築する必要はありません。 同時に、銀行などの重要で高価な情報が見つかった会社では、最も単純な決定とポリシーを無視するべきではありません。 この場合、IdMパラダイムで情報セキュリティを検討します。

思い出させてください。IdMとは、一連の測定、プロセス、技術的手段を意味します。つまり、すべての企業が複雑で高価な技術的IdMソリューションを必要とするわけではありません。 さらに、誰かがプロセスを紙の上ではなく実際に正しく構築するだけで十分です。 プロセスのためのプロセス、セキュリティのための安全性、ITのためのITは必要ありません。それらは割り当てられた機能を果たすだけであるため、ビジネス目標の達成に役立ちます。

それはどの結論ですか？ サイトを見つけて変更を加える必要があります。変更を加えることで、ユーザーの生活を改善し、ビジネスに利益をもたらします。 何をする必要があるかを理解するには、完全な調査を実施する必要があります。 論理的なものがあります：「 どこから始めればいいの？」

3つの簡単な質問から始める価値があります。

1. 何が欲しい？
2. なぜこれが必要なのでしょうか？
3. なぜこれが必要なのですか？

すぐに答えが出たら、いいです。 質問への回答は修正するのに役立ちますが、この段階で目標と目的の定義が完了したとは考えないでください。 回答では、あなたの視点と質問を読んだときに思いついたものだけを述べました。 このプロジェクトに参加する動機をより明確に理解するだけでなく、プロセスの他の参加者の 意見やニーズを知ることは非常に重要です。 そして、この情報を何らかの方法で修正します。

それとは別に、研究結果の固定を強調します。

• 事前にどのように調査を行い、回答を記録するかを考えてください。
• 記入するアンケートとテンプレートを準備します。
• 便利なプロトコルフォームまたはスコアカードを作成します。

多数の人とチャットするだけで、それぞれが異なる、時には予期しない何かを報告して尋ねる場合、誰が何を言ったのか、提案したのか、尋ねたのかを後で覚えることはほとんどありません。 自分の記憶だけに頼らないでください。 正式には組織フォームではなく、単にノートに書き留めます。 それは価値があります。

情報を収集するプロセスに進み、それに基づいてIdMの開発と実装の目標と目的を決定し、プロセス、対策、技術的ソリューションの要件を理解します。

最初に行うことは、ビジネス開発戦略（ある場合）を読むことです。 正式なドキュメントのみである場合もあれば、まったく存在しない場合もあります。 そうでない場合は、会社のリーダーに行って、ビジネスの最も差し迫ったニーズは何か、近い将来の会社の発展は何か、そしてITおよび情報セキュリティサービスの仕事からの個別の期待があるかについて話し合う必要があります。

このようなフィードバックの収集は定期的に行うことが望ましいです。 一方で、これは会社の経営陣と連絡を取り合うため、「 突然発生する 」要望や要件にショックを受けることはありません。 一方、受け取った情報により、ユニットの作業に対する満足度を確認し、ビジネスの利益のために機能する真に合理化された調和の取れたシステムを構築できます。

ユーザーが専門家に馴染みのある言葉で報告し、不平を言うことを期待することはほとんどありません。 「 品質 」と「 作業のスピード 」（測定方法と測定方法が不明な場合がほとんどです）、「 コスト削減 」、「 使いやすさ 」、「 シンプル 」、さらには「 美しく、イライラする 。」 または単に「仕事に行け！」あなたは聞いたことすべてに対処する必要がありますが、一度連絡をとれば、将来のリーダーシップの願いを理解しやすくなります。 まあ、そして：「誰がしようとしません、それ...」（あなた自身は何を知っていますか）。

2番目のステップは、ユーザー、IT /情報セキュリティサービス、およびプロセスに関係するビジネスサービス（人事部など）とのコミュニケーションです。 ユーザーの目を通してプロセスがどのように見えるかを理解し、ユーザーと一緒に「通過」する必要があります。 便利なサービスを構築してセキュリティを確保するには、ユーザーを知る必要があります。

• 彼らの習慣（たとえば、経理スタッフは、わかりにくいServiceDeskに申請書を記入するのではなく、「管理者Vasya」と呼ぶ習慣があるかもしれません）。
• ニーズ（たとえば、アクセスが緊急に必要であり、期限が切れている、検証が到着している、一度調整する人がいないなど）。
• 要件（たとえば、すべてが明確で透明であり、期限内に実行される必要があります）。
• 彼らの難しさ（企業のパーティーからの写真が保存されているネットワークフォルダーにアクセスするために紙に10個の署名を収集する必要がある場合、プロセスは明らかに何らかの形で機能します...）など

さらに、各ユーザーは重要です。 一般ユーザー、中間管理職、経営陣の悲しみや困難を聞く価値があります。

同様のアプローチは、同僚との作業に役立ちます。ITと情報セキュリティ（どちら側にいるのか）。 マネージャーとパフォーマーの両方のアドバイスを求め、IT /情報セキュリティの専門家の意見に耳を傾けることをお勧めします。 マネージャーはIT /情報セキュリティサービスの一般的な概念を知っています。誰が何に責任を持ち、新しいシステムを運用するための計画は何か、落とし穴は何か、規制当局の要件などは何でもあります。 同時に、アクセス権の付与と取り消し、アカウントの作成、パスワードを忘れたユーザーとのやり取り、さらにテクニカルサポートに電話で問い合わせるプロセス全体を、管理者よりも優れた人が教えたり見せたりすることはありません。 押すと、すべてが消えました... 」。 また、ServiceDeskまたはSEDでフォームがどのように遅くなるかを教えてくれます。

3番目のステップは、関心のあるビジネスユニットと連携することです。

次の人物は、アクセス制御を使用して順序を確立することに最も頻繁に関心を持っています。

• 人事部。 ここで重要なのは、新しい従業員が職場をすばやく整理し、アクセスをブロックして解雇され、休暇の専門家に正しく応答することなどです...（プロセスについては、次の記事で説明します。）
• すぐに仕事に取りかかる必要のある従業員が多い区画 （例：運用担当者、コールセンター、レジ係など）。
• 機密情報の取り扱い 、アクセスは厳格な規則に従って発行され、常に監視される必要があります。

各ユニットのヘッドと話し合うと便利です（階層の最上部から始めて、そのステップを下っていきます）。 私を信じて、あなたは多くの新しい予期しないことを学ぶでしょう。 たとえば、一部の従業員は1週間または2週間アクセスできない場合があります。 休暇中（病気休暇中）の直属の上司はフォームに署名できないため、アクセスを失った従業員は、すでに解雇された専門家のブロックされていない「記録」の下で作業します（これが実際のシナリオです）。

さらに、システムに外部の専門家が関与する部門を覚えておくことが重要です（ほとんどの場合はITですが、ビジネスユニットも同様のシナリオで機能する場合があります）：パートナー企業の従業員、サードパーティの請負業者の従業員（アウトソーシング、インテグレーター） 、ソフトウェア開発者、技術サポートなど）。 また、対話を構築し、どのように機能するか、 何を誰に、どのようにアクセスを提供するかを理解する必要があります 。

4番目のステップは、収集した情報の分析であるフィニッシュラインに近づきます。

この時点でまだ決断力があり、成果を上げる準備ができている場合は、続行します。

収集および記録された情報（繰り返しますが、すべてを記録して文書化してください。これはあなたの人生を大いに促進します！）確認された主な問題と希望で更新、分析、および策定する必要があります

IdMトピックの作業から得られた 各当事者の目標 、 目的 、 プロセスへの関与、および利点を反映するようにしてください。

目標と目標は何ですか？ ここでいくつか例を挙げますが、それらは教義としてではなく、反省の方向として認識されるべきです。

目的：会社の全従業員に対するアクセス制御の実装。

いくつかのタスク：

• 各情報システムのすべての従業員アカウントとアクセス権に関する最新情報を取得し、
• 情報システムにおける従業員のアクセス権を比較するための情報を含むレポートを受け取ります。

目的：システムAおよびBへのパートナー企業の従業員へのアクセス権を付与するための新しい手順の開発と導入。

いくつかのタスク：

• 新しい手順の設計と承認、
• 関係者およびユーザーのトレーニング、
• 使用のための新しい手順の紹介。

目的：ドメインポリシーを修正して、企業のセキュリティ標準への準拠を確保します。

いくつかのタスク：

• 企業標準との矛盾の特定と解消、
• ドメインポリシーの企業標準へのコンプライアンスを監視するメカニズムの開発と実装。

目的：会社の情報システムでアカウントを作成する手順の自動化。

目的：付与されたアクセス権を承認する手順の紹介。

目的：既存のアクセス制御手順に基づいたIdMソリューションの開発と試運転。

アクセス制御を使用する場合、目標はグローバルである必要はありません。 徐々に目的の状態に移行することをお勧めします。定義された目標が達成不可能と思われる場合は、計画を十分に検討せずに、プロジェクトの時間とリソースを計算します。 それは完全に異なっています-終わりが手段を正当化すること、すなわち あなたの会社の需要に「生きていた」。

可能であれば、IdMに関与する可能性のあるグループに研究結果を提示する価値があります。

なぜ「潜在的」なのですか？ この段階でこのトピックに取り組む必要があるという決定は、会社の上級管理職によってまだ行われていないためです。 すぐに上級管理職に紹介するというアイデアを思いついた場合、キーマネージャーまたは従業員の1人が「 それですべてが順調だ」 と主張するという事実に気付くかもしれません。 彼女/彼はIdM実装プロジェクトに参加したくありません（「 まあ、あなたは何ですか...さて、あなたは何かをしなければなりません、変更に慣れてください...今、すべてが魔法のように変わったなら！ 」）。 その結果、そのようなキャラクターはせいぜい何もせず、最悪の場合でも、あなたの良い仕事を明示的および暗示的に妨害します。

この状況から抜け出す方法は何ですか？ サポートを受ける。 プロジェクトに誰が興味を持っているかを理解し、実装の潜在的な利点、および参加のオプションと条件について話し合うことが重要です。 しかし、「IdMを実装しましょう」シリーズの会話だけでは役に立ちません。 各潜在的なプロジェクト参加者と同盟国に行く前に、IdM（つまり、アクセス制御プロセスと手順、およびそれらに伴う技術的ソリューション）の実装が、コミュニケーションをとるすべての人々の生活をどのように促進するかを伝えるのに役立つ議論を準備する必要があります。

IdMを実装する利点を示すと便利です。これは特に重要です！ - 関与の度合い と各参加者の役割を描く。 ほとんどの人は不確実性を恐れています。 各参加者の重要性、役割、労働を意図的に軽視したり、誇張したりしないでください。 何がどのように変化するかを正確に警告すると便利です。 これは、すべての関係者がプロジェクトに参加する準備ができていることです。

---

UPD。 続きを読む：

• パート3.2。 アクセスモデルを構築する方法
• パート3.3。 手順と技術的手段-基本からIdMまで。
• パート3.4。 問題を解決するには誰に行けばいいですか？