← プロジェクトに戻る

アイデンティティとアクセス

ID管理とZero Trustのラボ

コントロール プレーンとしてのアイデンティティに焦点を当てた実践的なセキュリティ ラボ: 認証、認可、条件付きアクセス、ライフサイクル管理、特権アクセス、実用的なゼロ トラスト設計。

Microsoft Entra IDID とアクセス管理MFA条件付きアクセスRBAC最低特権アカウントのライフサイクルZero Trust

プロジェクト概要

開発中
目的
アクセス制御、MFA、条件付きアクセス、特権アクセス、ライフサイクル管理、ゼロトラスト原則に重点を置いたシミュレートされたエンタープライズ ID 環境を構築します。
私の役割
個人ラボの調査、設計、ドキュメント作成。
実装状況
Conditional Access、MFA、およびロールベースのアクセス シナリオが進行中です。ライフサイクル ワークフロー、特権アクセス、正式なアクセス レビューは引き続き計画されています。
次のマイルストーン
ラボの開発に応じて、テナントの詳細が削除されたポリシーのエクスポート、役割マトリックス、予想されるアクセス テストと実際に観測されたアクセス テストを公開します。
事例紹介のソース(ポートフォリオ)↗

実装リポジトリ:未公開。

証拠と結果

作品が示すもの

開発中

Conditional Access、MFA、およびロールベースのアクセス シナリオが進行中です。ライフサイクル ワークフロー、特権アクセス、正式なアクセス レビューは引き続き計画されています。

  1. ユーザーID

  2. 認証 · MFA

  3. Conditional Access · 役割

  4. アプリケーションへのアクセス

ラボ向けの意図されたアクセス制御フロー。この図は設計を説明したものであり、完成した運用環境の展開ではありません。

記録された作業

  • このケース スタディでは、新入社員、役割変更、MFA 疲労、および特権管理のシナリオを定義します。
  • このラボでは、進行中の認証作業を、計画されたライフサイクルおよびアクセス レビューの演習から分離します。

次に公開する証拠

ラボの開発に応じて、テナントの詳細が削除されたポリシーのエクスポート、役割マトリックス、予想されるアクセス テストと実際に観測されたアクセス テストを公開します。

ソース リンクには、別の実装リポジトリではなく、この公開されたケース スタディが含まれています。

概要

なぜアイデンティティが優先されるのか

多くのセキュリティに関する決定は、最終的にはアイデンティティに関する決定になります。つまり、誰がアクセスを要求しているのか、何にアクセスできるのか、どのような条件でアクセスが許可されるべきなのか、そのアクセスは時間の経過とともにどのように変化するのかなどです。

このラボは、IAM の概念を MFA、条件付きアクセス、ロール設計、最小特権、ライフサイクル管理、特権アクセスに関する反復可能なシナリオに変えることで、認証理論を超えて進むように設計されています。

プロジェクトは意図的に反復的です。一部の制御はすでに検討されていますが、その他の制御は、サポートするラボ環境とポリシーがさらに構築されるまで計画のままです。

アイデンティティアーキテクチャ

ライフサイクルとしてのアクセス

01

アイデンティティ

アイデンティティを、システム、アプリケーション、および管理機能に誰がアクセスできるかを決定するためのコントロール プレーンとして扱います。

02

認証

MFA とより強力な認証制御を使用して、パスワードのみへの依存を減らします。

03

認可

個人に直接割り当てられる広範な権限ではなく、役割、グループ、最小限の権限に基づいてアクセスを設計します。

04

ライフサイクル

オンボーディング、役割の変更、異動、オフボーディングを通じて変更されるものとしてアクセスを管理します。

実験室での作業

私が作っているもの

ラボは、Entra ID の各機能を個別の演習として扱うのではなく、実践的なアイデンティティの問題を中心に編成されています。

現在の状態

条件付きアクセス、MFA、および役割ベースのアクセスは、現在の研究およびラボ開発の分野です。環境が成熟するにつれて、ライフサイクル ワークフロー、特権アクセス、正式なアクセス レビューが計画されます。

進行中

条件付きアクセス

認証要件、アクセス条件、ユーザー コンテキスト、アプリケーションの機密性、およびより強力な適用に関するシナリオを構築します。

進行中

MFA の施行

MFA ポリシーが実際の運用ワークフローとユーザー アクセスをサポートしながら、アカウントの侵害をどのように軽減できるかを研究しています。

進行中

ロールベースのアクセス

職務責任に基づいて権限をモデル化することで、直接割り当てではなく役割とグループを通じてアクセスを管理できるようになります。

予定

参加者 / 引っ越し者 / 退職者

ユーザーが組織内を移動する際にアクセスをプロビジョニング、変更、レビュー、削除するための反復可能なワークフローを設計する。

予定

特権アクセス

管理特権を標準のユーザー アクセスから分離し、制御されたワークフローに制限する方法を検討します。

予定

アクセスレビュー

権限が検証され、責任の変更に応じて不要なアクセスが削除されるように、定期的なレビューを計画します。

運用シナリオ

現実世界におけるアイデンティティの問題

最も有用な ID 演習は、管理者が実際に解決しなければならない問題を反映したものです。

01

新入社員

質問

What access should a new user receive on day one, and who should approve it?

アプローチ

Define access through role-based groups and documented ownership instead of copying another employee's permissions.

02

役割変更

質問

What happens when an employee changes departments or responsibilities?

アプローチ

Remove access that is no longer required before layering on new permissions so privileges do not accumulate indefinitely.

03

MFA疲労

質問

How should repeated unexpected MFA prompts be treated?

アプローチ

Treat unexpected prompts as a potential identity incident, contain the account, review authentication activity, and validate user behavior.

04

特権管理

質問

Should everyday user accounts carry administrative privileges?

アプローチ

Separate normal work from privileged administration and reduce standing access wherever practical.

05

オフボーディング

質問

How quickly should access disappear when a user leaves?

アプローチ

Disable identity access promptly, invalidate active sessions where appropriate, remove privileged access, and document completion.

06

アクセスドリフト

質問

How do permissions become excessive over time?

アプローチ

Use periodic review, ownership, documentation, and role-based assignment to identify and remove accumulated access.

Zero Trust

信頼を前提とする代わりにアクセスを検証する

01

明示的に検証する

位置だけに依存するのではなく、ID、認証強度、デバイス コンテキスト、リスク、およびその他の利用可能な信号を使用してアクセスの決定を行います。

02

最小限の特権を使用する

現在の役割に必要な権限のみを提供し、可能な限り継続的な管理アクセスを減らします。

03

違反を想定

侵害された 1 つの ID またはデバイスが自動的に環境内で無制限に移動できないようにアクセスを設計します。

「アイデンティティは、あなたが誰であるかよりも答えるべきです。アイデンティティは、あなたがどのような条件下で、どのくらいの期間、どこまで到達できるかを決定するのに役立つべきです。」

学んだ教訓

研究室が教えてくれること

01

ID セキュリティは、認証と同じくらいライフサイクルとガバナンスにも関係します。

02

環境が拡大するにつれて、直接割り当てられたアクセス許可を確認したり削除したりすることが困難になります。

03

MFA はセキュリティを向上させますが、ポリシー設計では依然としてユーザーの行動と運用上の現実を考慮する必要があります。

04

最小権限は、アクセスに明確な所有権があり、定義されたロールに関連付けられている場合に最適に機能します。

05

許可は時間の経過とともに自然に変化するため、文書化とアクセスのレビューが必要です。

次のステップ

ラボの拡張

01

追加の条件付きアクセス シナリオを構築する

02

参加者、移動者、離脱者のワークフローを作成する

03

役割とグループの設計を文書化する

04

特権アクセスのテストを拡張する

05

アクセスレビュー演習を追加する

06

ラボ管理をホスピタリティ IT シナリオにマッピングする

さらなるプロジェクト

研究室の残りの部分を探索してください。

プロジェクトに戻る →