ID での監査の説明

完了

ID ソリューションにおける監査の価値と目的を理解する必要があります。 監査を使用すると、管理者は既に発生した攻撃や現在進行中の攻撃を検出できます。 また、監査は、コンプライアンスと、どの ID で何が行われたかを追跡するためのツールです。 また、開発者がセキュリティ関連の問題をデバッグする際にも役立ちます。 たとえば、認証またはポリシー チェックの構成エラーによって承認済みユーザーへのアクセスが拒否された場合、開発者は、イベント ログを検査することによって、このエラーの原因をすばやく発見し、取り出すことができます。

サインインからパスワードの変更、多要素認証の構成と使用状況に至るまで、すべてのアクティビティをログに記録、報告、監視できます。 これらのログによって、ID とアクセスのソリューションがどのように実行されているかを確認するためのリソースが ID 管理者に提供されます。 健全な監査プラクティスによって ID が安全に保たれ、それによってデータとソリューションが安全に保たれます。 監査のために認識しておく必要があるさまざまなログには、Microsoft Entra アクティビティ ログ、サインイン ログ、プロビジョニング ログ、監査ログがあります。 Azure Monitor から Microsoft Sentinel まで、いくつかのツールを使用してレポートと監視を行うことができます。

ガバナンスの概念を理解する

Merriam-Webster の辞書には、ガバナンスはシステムの制御と方向を監視する行為またはプロセスであると書かれています。 そのシステムは、政府機関、予算、または Azure 上の ID ソリューションである可能性があります。 ガバナンスには、システムを運用すること、およびシステムの責任ある実行を評価することの両方のために、プロセスと制御が用意されます。 ソリューションを構築し、その後はそれを忘れてしまうのでは、とても十分とは言えません。 実行を監視したり、プロセスを定期的に更新したり、古い機能を削除または置き換えたりする必要があります。 そうしないと、システムは徐々に機能が低下してエラーになります。 Azure で構築する ID 管理ソリューションでもガバナンスは同じです。 システムを一定期間にわたって監視、評価、更新する必要があります。

シナリオ 単純ながら、ありそうなストーリー
アプリ開発者の Juan Juan という名前のユーザーがいます。 Juan は、会社のアカウントを与えられ、数年間勤務しています。 その間に、ユーザーである Juan には、構築を手伝ったアプリケーションをデプロイするための管理者アクセス権が付与されました。 その後、Juan は会社を円満退社しました。ただし、ユーザー アカウントはシステムから削除されていません。 Juan のマネージャーは、アカウントを削除するための書類を提出するのを忘れました。 そのアカウントが使用されていないこと、および Juan が人事システムに表示されなくなったことに気付くガバナンス システムがありません。 1 年後、Juan はフィッシング詐欺メールの被害を受け、個人用のユーザー名とパスワードを盗まれました。 多くの人々と同様に、Juan は私生活用のアカウントと職場アカウントに似たようなパスワードを使用していました。 その結果、有効なものと見なされるアカウントによってシステムに侵入されるシナリオができ上がります。

なぜガバナンスが必要なのでしょうか。 このシナリオでは、ガバナンスはさまざまな領域で役立ちます。

  • HR 部門に定期的に確認して、すべてのアカウントが HR データベースに従業員としてまだ存在していることを確かめます。
  • アカウントの最後のログイン日時を確認します。
  • アカウントに現在与えられているすべての権限が必要かどうかを確認します。
  • パスワードが定期的に変更されていることを確認します。または、より望ましいのは、従業員が MFA を使用することです。
  • その他多くの方法。

ID ライフサイクル管理の概念を理解する

ID ライフサイクル管理は ID 管理の基盤であり、大規模な効果的な管理には、アプリケーションの ID ライフサイクル管理インフラストラクチャの近代化が必要です。 ID ライフサイクル管理が目指すのは、デジタル ID のライフサイクル プロセス全体の自動化と管理です。

デジタル ID の管理は複雑な作業です。 実際のオブジェクト (個人や、個人と組織の関係など) を関連付ける必要があります。 ユーザーは、デジタル表現による組織の従業員と考えてください。 小規模な組織では、ID を必要とする個人のデジタル表現を維持することは、手動のプロセスになる可能性があります。 誰かが雇用されたり、請負業者が登録されたりしたときは、IT スペシャリストがディレクトリにアカウントを作成できます。 その後、彼らに必要なアクセス権が割り当てられます。 一方、中規模および大規模な組織では、自動化によって組織でスケーリングをすることができます。 自動化により、IT 部門は ID を正確に維持できます。

組織で ID ライフサイクル管理を確立するためのプロセスでは、通常、次のステップに従います。

  1. 既存の記録システム (組織で信頼できると見なされているデータ ソース) はありますか。 たとえば、組織で人事システムを利用しているとします。 それが、従業員とそのプロパティ (従業員の名前や部署など) の最新リストを確認する際に信頼できるシステムになります。
  2. その記録システムを、アプリケーションによって使用されるディレクトリやデータベース (1 つまたは複数) と比較し、ディレクトリと記録システムとの間に不整合があれば解決します。
  3. どのようなプロセスを使用すれば信頼できる情報をビジターに提供できるかを確認します。 ビジターのデジタル ID が不要になるときを把握するために、代わりとなる手段を見つける必要があります。

ID ライフサイクル管理の戦略

従業員、または組織と関係がある他の個人のための ID ライフサイクル管理を計画する必要があります。 多くの組織では、請負業者や学生ごとに "入社、異動、退社" のプロセスをモデル化します。 入社、異動、退社の定義は次のとおりです。

  • 入社 - アクセス権が必要な領域内に個人が立ち入るとき、それらの用途別に ID が必要となります。まだデジタル ID がなければ新たに作成する必要が生じる場合があります。
  • 異動 - 個人が境界を越えて移動するとき、新たなアクセス承認をデジタル ID に追加したり、そこから削除したりする必要があります。
  • 退社 - アクセス権が必要な領域から個人が離脱するときは、アクセス権を削除する必要があります。そうすると、その ID が監査やフォレンジクス以外の用途で必要になることはありません。

たとえば、組織に新しい従業員が入社し、その人物が過去にその組織に所属したことがない場合、その従業員には、Microsoft Entra ID 内のユーザー アカウントとして表される新しいデジタル ID が必要になります。 このアカウント作成は "入社" プロセスに分類され、自動化できます。 その後、組織内で、ある従業員が営業からマーケティングに異動することになったとしましょう。これは "異動" プロセスに該当します。 "異動" では、ユーザーが営業組織で持っていたアクセス権を削除する必要があります。この権限はもう必要ありません。 次に、マーケティング組織で必要となる権限を付与します。

監視ツール

常にゼロ トラストを想定する: 明示的に確認する - 最小限の特権アクセスを使用する - 侵害を想定する

監視サービス:

  • Azure Monitor
  • Application Insights
  • Azure Service Health
  • Azure Resource Health
  • Azure Resource Manager
  • Azure Policy