次の方法で共有

管理

  • [アーティクル]

管理とは、ビジネスに必要なサービス レベルを満たすために、情報技術 (IT) システムの監視、保守、運用を実践することです。 これらのタスクを実行するには、これらのシステムとアプリケーションの非常に広範なセットへの特権アクセスが必要なため、最も影響度の高い、いくつかのセキュリティ リスクが管理に伴って発生します。 管理特権を持つアカウントのアクセス権を取得すれば、標的とするデータの大半または全部にアクセスできることを攻撃者は知っているため、管理のセキュリティは最も重要なセキュリティ領域の 1 つです。

例として、Microsoft は自社のクラウド システムと IT システムの管理者の保護とトレーニングに多大な投資をしています。

A screenshot of a cell phone Description automatically generated

管理特権に関して Microsoft が推奨する中心戦略は、利用可能な制御を用いてリスクを低減することです

リスク露出 (スコープと時間) の低減 – 最小限の特権の原則は、オンデマンドで特権を提供する最新の制御によって最もよく達成されます。 これは、次の方法で、管理特権の露出を制限することによってリスクを制限するのに役立ちます。

  • スコープ – Just Enough Access (JEA: 必要最低限のアクセス) では、(ほとんどの場合に必要でない、多数またはすべてのシステムに対する直接かつ即時の特権を一度に与えるのではなく) 必要な管理操作に必要な特権のみを提供します。

  • 時間 – Just in Time (JIT) アプローチは、必要な特権を必要なときに提供するものでした。

  • 残りのリスクを軽減する – 予防的制御と検出的制御の組み合わせを使用してリスクを低減します。制御の例には、フィッシングや Web ブラウジング全般などの最も一般的なリスクから管理者アカウントを隔離する、管理者のワークフローを簡素化および最適化する、認証上の決定の確実性を高める、通常のベースライン動作からの例外を識別してブロックまたは調査できるようにする、などがあります。

Microsoft では、管理アカウントを保護するためのベスト プラクティスを捕捉して文書化し、特権アクセスを保護するための優先順位付きロードマップを公開しています。これらは、特権アクセスを持つアカウントに対する軽減策に優先順位を付けるためのリファレンスとして使用できます。

重大な影響がある管理者の数を最小限にする

ビジネスに重大な影響を与える可能性がある特権を付与するアカウントの数を最小限にします

個々の管理者アカウントは、攻撃者が標的にできる潜在的な攻撃面を表しているため、その特権を持つアカウントの数を最小限にすれば、組織全体のリスクを限定できます。 メンバーシップが積極的に制限および管理されていない場合、ユーザーの役割が刻々と変わるにつれて、これらの特権グループのメンバーシップが自然に増大することが経験からわかっています。

管理者に何らかの事態が発生した場合に備えて、ビジネスの継続性を確保しながら、この攻撃面のリスクを低減するアプローチをお勧めします。

  • ビジネスの継続性のために少なくとも 2 つのアカウントを特権グループに割り当てる

  • 2 つ以上のアカウントが必要な場合は、最初の 2 人を含めたメンバーごとに正当な理由を用意する

  • 各グループ メンバーのメンバーシップと正当な理由を定期的に確認する

管理者用のマネージド アカウント

組織のポリシー施行に従うために、重大な影響がある管理者全員が必ず、エンタープライズ ディレクトリによって管理されるようにします。

@Hotmail.com、@live.com、@outlook.com などの Microsoft アカウントのようなコンシューマー アカウントでは、組織のポリシーや規制要件を確実に遵守するための、十分なセキュリティの可視性と制御は提供されません。 Azure のデプロイは、エンタープライズ管理のテナントに成長する前に、小さな規模で非公式な形で始まることが多いため、(当初の Azure プロジェクト マネージャーのような) 一般ユーザーのアカウントが管理アカウントとして後々長く残り、死角や潜在的なリスクとなることがあります。

管理者用のアカウントを分離する

重大な影響がある管理者全員が、(電子メール、Web ブラウジング、その他の生産性タスクに使用するアカウントとは別に) 管理タスク用の独立したアカウントを持っていることを確認します。

フィッシング攻撃や Web ブラウザー攻撃は、管理者アカウントを含むアカウントを侵害するための最も一般的な攻撃ベクトルです。

クリティカルな特権が必要な役割を持っているユーザー全員に、独立した管理者アカウントを作成します。 これらの管理アカウントについては、Office 365 電子メールなどの生産性ツールをブロック (ライセンスを削除) してください。 可能であれば、(プロキシやアプリケーション制御を使用して) 自由な Web ブラウジングをブロックする一方で、Azure portal や、管理タスクに必要なその他のサイトをブラウズするための例外を許可します。

継続的なアクセスを付与しない/Just in Time 特権

重大な影響があるアカウントには永続的な "継続的" アクセスを提供しない

永続的な特権は、攻撃者が危害を加えるためにアカウントを使用できる時間を増やすことによってビジネス リスクを高めます。 一時的な特権により、攻撃者は、管理者が既にアカウントを使用している限られた時間内で攻撃を仕掛けるか、それとも特権昇格を開始するか (この場合、検出されて環境から排除される可能性も高まります) のどちらかにアカウントの狙いを絞ることを余儀なくされます。

次のいずれかの方法を使用して、必要な場合にのみ必要な特権を付与します。

  • Just in Time - Microsoft Entra Privileged Identity Management (PIM) またはサードパーティのソリューションで、重大な影響があるアカウントに対する特権を取得するには承認ワークフローに従うことを必須化できるようにします

  • ガラス破り – めったに使用されないアカウントの場合は、アカウントにアクセスするための緊急アクセス プロセスに従います。 これは、グローバル管理者アカウントのメンバーなど、通常の運用ではほとんど使用する必要がない特権に適しています。

緊急アクセスまたは "ガラス破り" アカウント

緊急時に管理アクセス権を取得するためのメカニズムがあることを確認します

まれに、通常の管理アクセス手段がすべて利用できない極端な状況が発生することがあります。

「Microsoft Entra ID で緊急アクセス用管理アカウントを管理する」の手順に従って、必ず、セキュリティ操作でこれらのアカウントを慎重に監視することをお勧めします。

管理ワークステーションのセキュリティ

重大な影響がある管理者は、必ず、セキュリティの保護と監視が昇格したワークステーションを使用するようにします

フィッシングのように、ブラウジングや電子メールを使用する攻撃ベクトルは、低コストで一般的です。 重大な影響がある管理者をこれらのリスクから隔離すれば、これらのアカウントのいずれかが侵害されて、ビジネスや任務に大損害を与えるために利用される重大インシデントのリスクが大幅に下がります。

https://aka.ms/securedworkstation で利用可能なオプションに基づいて、管理ワークステーションのセキュリティ レベルを選択します

  • 安全性の高い生産性デバイス (セキュリティ強化ワークステーションまたは専用ワークステーション)
    重大な影響がある管理者のセキュリティのための行程は、セキュリティが強化されているが一般的なブラウジングや生産性タスクにも使用できるワークステーションを管理者に提供することから開始できます。 これを暫定的なステップとして使用すれば、重大な影響がある管理者と、当該管理者およびその使用ワークステーションをサポートする IT スタッフのどちらにとっても、完全に隔離されたワークステーションへの移行が容易になります。

  • 特権アクセス ワークステーション (専用ワークステーションまたはセキュリティで保護されたワークステーション)
    これらの構成は、フィッシング、ブラウザー、生産性アプリケーションの各攻撃ベクトルへのアクセスを大幅に制限する点で、重大な影響がある管理者にとって理想的なセキュリティ状態を表します。 これらのワークステーションは、一般的なインターネット ブラウジングは許可せず、Azure portal やその他の管理用サイトへのブラウザー アクセスのみを許可します。

重大な影響がある管理者の依存関係 – アカウント/ワークステーション

重大な影響があるアカウントとその使用ワークステーションについて、オンプレミスのセキュリティ依存関係を慎重に選択します

オンプレミスの重大インシデントが波及してクラウド資産の大規模侵害に至る前にリスクを封じ込めるには、重大な影響があるクラウド内のアカウントに対してオンプレミスのリソースが持っている制御手段を排除または最小化する必要があります。 たとえば、オンプレミスの Active Directory を侵害する攻撃者は、Azure、アマゾン ウェブ サービス (AWS)、ServiceNow などにあるリソースのように、それらのアカウントに依存するクラウドベースの資産にアクセスして侵害することができます。 攻撃者は、それらのオンプレミス ドメインに参加しているワークステーションを使用して、そこから管理されているアカウントやサービスにアクセスすることもできます。

重大な影響があるアカウントに対するオンプレミスの制御手段 (セキュリティ依存関係とも呼ばれる) からの隔離レベルを選択する

  • ユーザー アカウント – 重要な影響があるアカウントをホストする場所を選択します

    • ネイティブ Microsoft Entra アカウント -*オンプレミスの Active Directory と同期されないネイティブの Microsoft Entra アカウントを作成します

    • オンプレミスの Active Directory から同期する (非推奨) - オンプレミスの Active Directory でホストされている既存のアカウントを利用します。

  • ワークステーション – クリティカルな管理者アカウントによって使用されるワークステーションを管理およびセキュリティで保護する方法を選択します。

    • ネイティブ クラウド管理とセキュリティ (推奨) - ワークステーションを Microsoft Entra ID に参加させ、Intune またはその他のクラウド サービスで管理/修正プログラムを適用します。 Windows の Microsoft Defender ATP、または、オンプレミス ベースのアカウントによって管理されない別のクラウド サービスを使用して保護と管理を行います。

    • 既存のシステムによる管理 - 既存の AD ドメインに参加し、既存の管理/セキュリティを利用します。

管理者向けのパスワードレス認証または多要素認証

重大な影響がある管理者全員に、パスワードレス認証または多要素認証 (MFA) の使用を義務付けます。

攻撃方法は、パスワードだけではアカウントを確実に保護できないレベルに進化しています。 これについては、Microsoft Ignite セッションに詳しい記載があります。

管理者アカウントとすべてのクリティカル アカウントは、次の認証方法のいずれかを使用する必要があります。 これらの機能は、攻撃のコスト/難易度が最も高いもの (最も強力/優先されるべきオプション) から、攻撃のコスト/難易度が最も低いものの順に列挙しています。

  • パスワードなし (Windows Hello など)
    https://aka.ms/HelloForBusiness

  • パスワードレス (Authenticator アプリ)
    </azure/active-directory/authentication/howto-authentication-phone-sign-in>

  • 多要素認証
    </azure/active-directory/authentication/howto-mfa-userstates>

注意点として、SMS テキスト メッセージを使った MFA は、攻撃者がきわめて低コストで回避できるようになっているため、この方法には頼らないことをお勧めします。 このオプションは、パスワード単体よりはまだ強力ですが、他の MFA オプションよりはずっと脆弱です

管理者の条件付きアクセスを強制する - ゼロ トラスト

ゼロ トラスト戦略をサポートするために、重要なセキュリティ属性の測定および施行を、すべての管理者およびその他の重大な影響があるアカウントの認証に含める必要があります。

Azure 管理者アカウントを侵害する攻撃者は、深刻な被害をもたらす可能性があります。 条件付きアクセスは、Azure 管理へのアクセスを許可する前にセキュリティの検疫を実施することで、このリスクを大幅に低減できます。

組織のリスク選好度と運用上のニーズを満たす Azure 管理の条件付きアクセス ポリシーを構成します。

  • 多要素認証または指定された職場ネットワークからの接続 (あるいはその両方) を要求します

  • Microsoft Defender ATP との整合性をデバイスに要求します (強い保証)

きめ細かなカスタム アクセス許可の回避

個々のリソースまたはユーザーを特に参照するアクセス許可を避けます

特定のアクセス許可は、新しい同様のリソースに意図が引き継がれないため、不必要な複雑さや混乱を生じさせます。 維持するにしても変えるにしても "何かを壊す" ことへの恐れから逃れることが難しい複雑なレガシ構成に、そのような不安要素が蓄積されることで、セキュリティにもソリューションの機敏性にも悪影響が及びます。

特定のリソースに固有のアクセス許可を割り当てる代わりに、次のどちらかを使用します

  • 企業全体のアクセス許可用の管理グループ

  • サブスクリプション内のアクセス許可用のリソース グループ

特定のユーザーにアクセス許可を付与する代わりに、Microsoft Entra ID 内のグループにアクセスを割り当てます。 適切なグループがない場合は、ID チームと協力して作成します。 これにより、Azure の外部でグループ メンバーを追加および削除したり、アクセス許可が最新であることを確認したりできる一方で、メーリング リストなどの他の目的にもグループを使用できます。

組み込みのロール

可能な場合は、組み込みのロールを使用してアクセス許可を割り当てます。

カスタマイズは複雑さにつながり、混乱を増やし、自動化をより複雑で、困難で、脆弱なものにします。 これらの要素はすべてセキュリティに悪影響を及ぼします

ほとんどの通常シナリオに対応するように設計された組み込みのロールを評価することをお勧めします。 カスタム ロールは強力で、時には便利な機能ですが、組み込みのロールでうまくいかない場合のために取っておくことをお勧めします。

重大な影響があるアカウントのライフサイクル管理を確立する

管理者が組織を離れた (または管理職から退いた) ときに管理アカウントを無効化または削除するプロセスがあることを確認します

詳細については、「アクセス レビューによるユーザーとゲスト ユーザーのアクセス管理」をご覧ください。

重大な影響があるアカウントに対する攻撃のシミュレーション

最新の攻撃手法を用いて、管理者ユーザーに対する攻撃を定期的にシミュレートすることで、ユーザーを教育し、必要な能力を身に付けさせます。

ユーザー、特に、重大な影響があるアカウントにアクセスできるユーザーは、防御の重要な要素です。 攻撃を防ぎ、攻撃に耐えるための知識とスキルを、これらのユーザー (理想的にはユーザー全員) が確実に習得すれば、組織全体のリスクが低減されます。

Office 365 の攻撃シミュレーション機能、またはサードパーティ製の機能をいくつでも使用できます。

次のステップ

Microsoft によるその他のセキュリティ ガイドは、Microsoft の「セキュリティのドキュメント」をご覧ください。