Azure のセキュリティに関するベスト プラクティス

  • [アーティクル]

この記事では、セキュリティに関する推奨されるベスト プラクティスについて説明します。これは、お客様から、また独自の環境における経験から得た教訓に基づいています。

ビデオ プレゼンテーションについては、Azure のセキュリティに関するベスト プラクティス に関するビデオをご覧ください。

1.ユーザー: クラウド セキュリティのための移行の過程についてチームを教育する

"チームは、自分たちが進む移行の過程を理解している必要があります。 "

何ですか?

セキュリティ担当および IT 担当チームに、クラウド セキュリティのための移行の過程と、対処することになる次のような変化について教育します。

  • クラウド内の脅威
  • 責任共有モデルと、それがセキュリティに与える影響
  • クラウド導入に一般的に付随するカルチャとロールおよび責任の変化

なぜでしょうか。

クラウド セキュリティには、考え方とアプローチのシフトが必要です。 セキュリティが組織にもたらす結果は変化しませんが、クラウドでこの結果を実現するための最善の方法は大幅に変化することがあります。

クラウドへの移行は、戸建て住宅から高層マンションに引っ越すようなものです。 基本的なインフラ (水道設備や電気など) は引き続き維持し、同じような活動 (交際、料理、テレビとインターネットなど) を行います。 ただし、多くの場合、建物の付属施設、それを提供して維持する人、毎日の決められた作業には大きな違いがあります。

誰がですか?

CIO や CISO から技術者に至るまで、セキュリティおよび IT の組織でセキュリティの職責にある全員が、この変化を理解している必要があります。

方法はありますか。

クラウド環境への移行時にデプロイおよび運用を適切に行うために必要なコンテキストをチームに提供します。

Microsoft は、お客様と自社の IT 組織がクラウドへの移行の過程で得た、以下の教訓を公開しています。

詳細については、Azure セキュリティ ベンチマークのロール、責任、責務に関する説明を参照してください。

2.ユーザー: クラウド セキュリティ テクノロジについてチームに教育する

"どこに向かっているのかを皆が理解する必要があります。 "

何ですか?

次のようなクラウド リソースのセキュリティ保護に関する技術教育のために、チームの時間を確保します。

  • クラウド テクノロジとクラウド セキュリティ テクノロジ
  • 推奨される構成とベスト プラクティス
  • 技術的な詳細情報の取得先

なぜでしょうか。

技術チームは、情報に基づいたセキュリティ上の意思決定を行うために、技術情報にアクセスできる必要があります。 技術チームは実際の職務を通じて新しいテクノロジを学ぶことに優れていますが、多くの場合、クラウドの詳細情報の量は、学習を日常業務に適合させる彼らの能力を上回ります。

技術の学習に専念する時間を作ります。 学習することにより、クラウドのセキュリティを評価する能力に自信をつける時間を確保できます。 これにより、既存のスキルとプロセスをどのように適合させるかをじっくり考えることができるようになります。

誰がですか?

クラウド テクノロジを直接操作する、セキュリティと IT のすべてのロールに、クラウド プラットフォームとそのセキュリティ保護の方法に関する技術の学習に専念する時間を確保する必要があります。

セキュリティ、IT 技術マネージャー、およびプロジェクト マネージャーは、クラウド リソースを保護するための技術的な詳細について理解を深めることができます。 この理解により、クラウドのイニシアチブをより効果的に主導および調整できるようになります。

方法はありますか。

セキュリティの技術担当者が、クラウド資産をセキュリティで保護する方法に関するトレーニングをマイペースで進められるように時間を確保します。 常に実現できるとは限りませんが、熟練したインストラクターとハンズオン ラボが用意された正式なトレーニングにアクセスできるようにします。

重要

ID プロトコルは、クラウドでのアクセスの制御に不可欠ですが、オンプレミスのセキュリティでは優先されないことがよくあります。 セキュリティ チームは、これらのプロトコルとログに精通することに集中する必要があります。

Microsoft は、技術担当者が能力を強化するうえで役立つ広範なリソースを提供しています。 これらのリソースには次が含まれます。

3.プロセス:クラウドのセキュリティに関する意思決定の説明責任を割り当てる

セキュリティに関する意思決定は、その説明責任を負う者がいなければ行われません。

何ですか?

エンタープライズ Azure 環境に対して各種のセキュリティ上の意思決定を行う担当者を選びます。

なぜでしょうか。

セキュリティに関する意思決定の担当者を明確にすると、クラウドの導入スピードがアップし、セキュリティも向上します。 一般に、当事者意識がないと摩擦が生じます。これは、だれも意思決定を行う権限を持っていると実感していないからです。 だれに意思決定を求めるべきかが不明であり、情報に基づく意思決定を探求する動機がないのです。 摩擦が、以下の妨げとなることがよくあります。

  • ビジネス目標
  • 開発者のタイムライン
  • IT 目標
  • セキュリティ保証

摩擦は、以下を招く可能性があります。

  • セキュリティ承認待ちによるプロジェクトの停滞
  • セキュリティの承認を待つことができなかった安全でないデプロイ

誰がですか?

セキュリティ リーダーが、クラウドに関するセキュリティ上の意思決定を行うことに説明責任を負うチームまたは個人を選びます。

方法はありますか。

主要なセキュリティ上の意思決定を行う責任を持つグループ (または個人) を選びます。

これらの当事者とその連絡先情報を文書化し、セキュリティ、IT、クラウドの各担当チーム内でこれを広く知らせます。 広く知らせることにより、すべてのロールがその人たちに簡単に連絡を取れるようになります。

これらの領域は、通常、セキュリティ上の決定が必要です。 次の表に、意思決定のカテゴリ、カテゴリの説明、および意思決定を担当することの多いチームを示します。

決定 説明 一般的なチーム
ネットワークのセキュリティ Azure Firewall、ネットワーク仮想アプライアンスおよび関連するルーティング、Web アプリケーション ファイアウォール (WAF)、NSG、ASG などの構成と保守を行います。 ネットワーク セキュリティに焦点を絞ったインフラストラクチャとエンドポイントのセキュリティ チーム
ネットワーク管理 企業全体の仮想ネットワークとサブネットの割り当てを管理します。 中央 IT 運用の既存のネットワーク運用チーム
サーバー エンドポイントのセキュリティ サーバー セキュリティ (修正プログラムの適用、構成、エンドポイントのセキュリティなど) の監視と修復を行います。 中央 IT 運用とインフラストラクチャとエンドポイントのセキュリティの担当チームが共同で行う
インシデントの監視と対応 SIEM またはソース コンソール (Microsoft Defender for Cloud、Microsoft Entra ID Protection など) でセキュリティ インシデントを調査して修復します。 セキュリティ運用チーム
ポリシー管理 Azure リソースの管理において、Azure ロールベースのアクセス制御 (Azure RBAC)、Defender for Cloud、管理者保護戦略、Azure Policy を使用する方針を決めます。 ポリシーと標準とセキュリティ アーキテクチャの担当チームが共同で行う
ID に関するセキュリティと標準 Microsoft Entra のディレクトリ、PIM/PAM の使用、多要素認証、パスワードまたは同期の構成、アプリケーション ID 標準についての指針を定めます。 ID とキーの管理、ポリシーと標準、セキュリティ アーキテクチャの担当チームが共同で行う

Note

  • 意思決定者は、この責任が伴うクラウドの領域において適切な教育を受けている必要があります。
  • 記録を残し、組織を長期にわたって導くために、決定事項をポリシーと標準に確実に文書化します。

4. プロセス:クラウドのインシデント対応プロセスを更新する

計画は前もって行います。 "緊急時に緊急時の計画を立てる時間はありません。 "

何ですか?

Azure クラウド プラットフォーム上のセキュリティ インシデントに対して準備します。 この準備には、採用したネイティブの脅威検出ツールが含まれます。 プロセスを更新し、チームを準備して、インシデント調査、修復、脅威ハンティング時に最大限の力を発揮できるように、シミュレートされた攻撃を使用して練習します。

なぜでしょうか。

アクティブな攻撃者は、差し迫ったリスクを組織にもたらします。 状況はすぐに制御が困難になる可能性があります。 攻撃に迅速かつ効果的に対応してください。 エンタープライズ データ、システム、アカウントをホストしているすべてのクラウド プラットフォームを含む資産全体に対して、このインシデント対応 (IR) プロセスを有効にする必要があります。

多くの類似点はありますが、クラウド プラットフォームは技術的にはオンプレミス システムとは異なります。 オンプレミス システムは、既存のプロセスを破綻させる可能性があります。これは、通常、情報が別の形式で使用できるためです。 セキュリティ アナリストは、不慣れな環境に迅速に対応することになり、そのために対応が遅れる可能性があるという課題を抱えている場合があります。 これに特に該当するのは、従来のオンプレミス アーキテクチャとネットワークやディスクのフォレンジックア プローチについてのみトレーニングを受けている場合です。

誰がですか?

IR プロセスの最新化は、通常、セキュリティ運用部門によって主導されます。 この取り組みは、知識と専門知識の面で他のグループからのサポートを伴います。

  • スポンサー: 通常、セキュリティ運用担当部長 (または同等のスポンサー) がプロセスの最新化を主催します。

  • 実行 - 既存のプロセスを適合させる (または、初めて作成する) ことは、次のことを含む共同作業です。

    • セキュリティ運用: インシデント管理のチームまたはリーダーが、プロセスと統合の更新情報を主要な外部関係者に伝達するのを指揮します。 これらのチームには、法務およびコミュニケーション、または広報のチームが含まれます。
    • セキュリティ運用: セキュリティ アナリストが技術的なインシデントの調査とトリアージに関する専門知識を提供します。
    • 中央 IT 運用: クラウド プラットフォームに関する専門知識を (クラウドのセンター オブ エクセレンスを通じて直接、または外部のコンサルタントを通じて) 提供します。

方法はありますか。

プロセスを更新し、アクティブな攻撃者を見つけたときに何をすればよいかがわかるように、チームを準備します。

  • プロセスとプレイブック: 既存の調査、修復、脅威ハンティングのプロセスを、クラウド プラットフォームのしくみの違いに合わせて調整します。 違いとは、新しい、または異なるツール、データ ソース、ID プロトコルなどです。
  • 教育: クラウド全体の変革、プラットフォームのしくみに関する技術的な詳細、新しいまたは更新されたプロセスについてアナリストを教育します。 この情報から、何が変わるのか、必要なものがどこで見つかるかを把握できるようになります。
  • 主要な対象領域: リソースのリンクには多くの詳細が記載されていますが、教育および計画の取り組みで重点を置くべき領域はこちらです。
    • 共有責任モデルとクラウド アーキテクチャ: セキュリティ アナリストにとって、Azure は、多くのサービスを提供する、ソフトウェア定義のデータセンターです。 サービスとしては、VM その他 (Azure SQL Database や Azure Functions など) があり、これはオンプレミスとはまったく異なります。 有用なデータは、サービス ログまたは特殊な脅威検出サービスの中にあります。 基礎となっている OS/VM (Microsoft によって運用され、複数のお客様にサービスが提供されているもの) のログの中にあるのではありません。 アナリストは、このコンテキストを理解して日常のワークフローに統合する必要があります。 これにより、予想されるデータ、それを取得する場所、それに使用される形式がわかるようになります。
    • エンドポイント データ ソース: ネイティブ クラウド検出ツールを使用すると、クラウドでホストされているサーバー上の攻撃やマルウェアに関する分析情報やデータの取得が、より高速、簡単、正確に行えるようになります。 Microsoft Defender for Cloud やエンドポイントでの検出と対応 (EDR) ソリューションなどのツールでは、直接ディスク アクセスという従来のアプローチと比べて、より正確なデータが得られます。 直接ディスクのフォレンジクスは、それが可能であり法的手続きのために必要とされるシナリオで利用可能です。 詳細については、Azure でのコンピューター フォレンジクスに関する記事を参照してください。 ただし、このアプローチは、攻撃を検出して調査する方法として最も非効率的です。
    • ネットワークと ID のデータ ソース: クラウド プラットフォームの多くの機能では、主に ID を使用してアクセス制御が行われます。 これには、Azure portal へのアクセスなどのアクセス制御が含まれますが、ネットワーク アクセス制御も広く使用されています。 このアクセス制御のためには、アナリストはクラウド ID プロトコルについて理解を深め、インシデントの調査と修復をサポートするために、攻撃者のアクティビティおよび正当なユーザー アクティビティについて完全で詳細な全体像を把握する必要があります。 ID ディレクトリとプロトコルは、オンプレミスのものとは異なります。 通常は、LDAP、Kerberos、NTLM、Active Directory ではなく、SAML、OAuth、OpenID Connect、およびクラウド ディレクトリに基づいています。
    • 実習: シミュレートされた攻撃と対応は、組織の反射的対応と技術的な準備を確立するのに役立ちます。 組織内のセキュリティ アナリスト、脅威ハンター、インシデント マネージャー、およびその他の関係者にとって、準備となります。 実際の職務を通じて学び、適応することは、インシデント対応において当たり前のことですが、緊急時に学ばなければならないことを最小限に抑えるように取り組むことができます。

主要リソース

詳細については、Azure セキュリティ ベンチマークの Azure のインシデント対応プロセスに関する説明を参照してください。

5.プロセス:セキュリティ態勢管理を確立する

"まず、自らを知ること。 "

何ですか?

次のようにして、Azure 環境のセキュリティ態勢を積極的に管理するようにします。

  • 次に対する責任の明確な担当者を割り当てる。
    • セキュリティ体制の監視
    • 資産に対するリスクの軽減
  • これらのタスクの自動化と簡略化

なぜでしょうか。

セキュリティの検疫に関する一般的なリスクを迅速に特定して修復すると、組織としてのリスクが大幅に軽減されます。

ソフトウェア定義というクラウド データセンターの性質のため、広範な資産のインストルメンテーションによって、ソフトウェアの脆弱性やセキュリティ構成の不備などのセキュリティ リスクを継続的に監視できます。 開発者と IT チームが VM、データベース、その他のリソースをすばやくデプロイできるようにするには、リソースが安全に構成されて積極的に監視されるようにする必要性が生じます。

これらの新しい機能によって新しい可能性が提供されますが、それらから価値を実現するには、それらを使用するための責任を割り当てる必要があります。 急速に進化するクラウド運用を継続的に実行するには、人が行うプロセスを可能な限り簡素化し、自動化する必要があります。 セキュリティ原則の「シンプルさを促進する」を参照してください。

Note

簡素化とオートメーションの目標は、職を排除することではなく、反復的なタスクの負担を人々から取り除くことで、IT チームや DevOps チームとの提携や教育など、より価値の高い、人間のアクティビティに専念できます。

誰がですか?

通常、これは次の 2 組の責任に分けられます。

  • セキュリティ態勢管理: この機能は、多くの場合、既存の脆弱性管理またはガバナンス機能が進化したものです。 この結果には、Microsoft Defender for Cloud セキュリティ スコアで保護されたスコアやその他のデータ ソースを使用した全体的なセキュリティ態勢の監視が含まれます。 これには、リスクを軽減するためにリソース所有者と積極的に連携すること、セキュリティ リーダーへのリスクの報告が含まれます。

  • セキュリティ修復: これらのリスクに対処することについての説明責任を、これらのリソースの管理を担当するチームに割り当てます。 この説明責任は、独自のアプリケーション リソースを管理している DevOps チームか、中央 IT 運用のテクノロジ専門チームに属している必要があります。

    • コンピューティングおよびアプリケーションのリソース
      • アプリケーション サービス: アプリケーション開発およびセキュリティ チーム
      • コンテナー: アプリケーション開発またはインフラストラクチャ/IT 運用
      • VM、スケールセット、コンピューティング: IT/インフラストラクチャ運用
    • データおよびストレージのリソース
      • SQL、Redis、Data Lake Analytics、データ レイク ストア: データベース チーム
      • ストレージ アカウント: ストレージおよびインフラストラクチャ チーム
    • ID およびアクセス リソース
      • サブスクリプション: ID チーム
      • Key Vault: ID または情報/データ セキュリティ チーム
    • ネットワーク リソース: ネットワーク セキュリティ チーム
    • IoT セキュリティ: IoT 運用チーム

方法はありますか。

セキュリティは全員の仕事です。 しかし、それがどれだけ重要か、何をどのように行うのかを全員が知っているわけではありません。

  • リソース所有者が可用性、パフォーマンス、コスト、およびその他の成功要因について説明責任を負うのと同様に、セキュリティ リスクについて説明責任を負うようにします。
  • セキュリティ リスクが資産にとって重要である理由、リスクを軽減するために何ができるのか、生産性の低下を最小限に抑えてそれを実装する方法についてリソース所有者が明確に理解できるようにサポートします。

重要

多くの場合、リソースをセキュリティで保護する理由、対象、方法についての説明は、リソースの種類が異なっても類似していますが、各チームが既に知っていて配慮していることに関連付けることが重要です。 セキュリティ チームは、チームを成功させることに焦点を合わせた信頼できるアドバイザー兼パートナーとして、IT および DevOps チームと連携できます。

ツール: Microsoft Defender for Cloud のセキュリティ スコアは、Azure において最も重要なセキュリティ情報の評価を表すものであり、さまざまな資産を対象としています。 この評価は、態勢管理の出発点となるものであり、カスタムの Azure ポリシーやその他のメカニズムで必要に応じて補完できます。

頻度: Azure セキュリティ スコアを一定の頻度 (通常は月 1 回) で確認するように設定し、具体的な改善目標を定めたイニシアチブを計画します。 頻度は必要に応じて増やすことができます。

ヒント

可能な場合は、アクティビティをゲーム化してエンゲージメントを高めます。たとえば、DevOps チーム向けにスコアを最も高める楽しいコンテストや賞を作ります。

詳細については、Azure セキュリティ ベンチマークのセキュリティ態勢管理の戦略に関する説明を参照してください。

6. テクノロジ: パスワードレスまたは多要素認証を必須にする

"自社のセキュリティは、間違いなく専門の攻撃者が管理者のパスワードを推測したり盗んだりできないものだと言えますか? "

何ですか?

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

なぜですか?

古いスケルトン キーでは現代の泥棒から家を守ることができないのと同じように、パスワードでは、一般的な攻撃からアカウントを保護することはできません。 技術的な詳細については、パスワードは重要ではないに関する記事を参照してください。

かつては、多要素認証は面倒な追加の手順でした。 現在のパスワードレス アプローチでは、ユーザーのサインイン方法が向上し、Windows Hello やモバイル デバイスの顔認識などの生体認証アプローチが使われています。 さらに、ゼロ トラスト アプローチでは、信頼されたデバイスが記憶されます。 この方法により、面倒で付加的な多要素認証アクションを求められることが減ります。 詳細については、ユーザー サインインの頻度に関するページを参照してください。

誰がですか?

パスワードと多要素の取り組みは、通常、ID とキーの管理またはセキュリティ アーキテクチャによって主導されます。

方法はありますか。

パスワードレスまたは多要素認証を実装します。 その使用方法について管理者をトレーニングします (必要な場合)。また、管理者に対して、策定されたポリシーを使用して従うように要求します。 次の 1 つ以上のテクノロジを使います。

Note

現時点では、テキスト メッセージベースの多要素認証は、攻撃者にとってすり抜ける手間が比較的かからないため、パスワードレスおよびより強力な多要素認証に重点を置いてください。

詳細については、Azure セキュリティ ベンチマークのすべての Microsoft Entra ID ベースのアクセスの強力な認証コントロールに関する記事を参照してください。

7.テクノロジ: ネイティブ ファイアウォールとネットワーク セキュリティを統合する

"ネットワーク攻撃に対するシステムとデータの保護を簡略化します。 "

何ですか?

Azure Firewall、Azure Web App Firewall (WAF)、および分散型サービス拒否 (DDoS) の緩和策をネットワーク セキュリティ アプローチに統合することによって、ネットワークのセキュリティ戦略とメンテナンスを簡略化します。

なぜでしょうか。

わかりやすくすることはセキュリティにとって重要です。そうすることで、混乱、誤りの防止、およびその他の人為的なエラーによるリスクの可能性が軽減されるからです。 セキュリティ原則の "シンプルさを促進する" に関する記事を参照してください。

ファイアウォールと WAF は、悪意のあるトラフィックからアプリケーションを保護するための重要な基本セキュリティ制御ですが、そのセットアップとメンテナンスは複雑で、セキュリティ チームの多くの時間と注意を費やすことがあります (カスタムのアフターパーツを車に追加するのと同様)。 Azure のネイティブ機能を使用すると、ファイアウォール、Web アプリケーション ファイアウォール、分散型サービス拒否 (DDoS) の軽減策などの実装と運用を簡単に行うことができます。

この方法により、次のような価値の高いセキュリティ タスクにチームの時間と注意を向けることができます。

  • Azure サービスのセキュリティの評価
  • セキュリティ運用の自動化
  • セキュリティとアプリケーションおよび IT ソリューションの統合

誰がですか?

  • スポンサー: このネットワーク セキュリティ戦略の更新は通常、セキュリティ リーダーまたは IT リーダーが主催します。
  • 実行: 戦略をクラウド ネットワークのセキュリティ戦略に統合することは、次を含む共同作業です。
    • セキュリティ アーキテクチャ: クラウド ネットワークおよびクラウド ネットワーク セキュリティのリーダーとのクラウド ネットワーク セキュリティ アーキテクチャを確立する。
    • クラウド ネットワークのリーダー (中央 IT 運用) および クラウド ネットワーク セキュリティのリーダー (インフラストラクチャ セキュリティ チーム)
      • セキュリティ アーキテクトと共にクラウド ネットワークのセキュリティ アーキテクチャを確立する。
      • ファイアウォール、NSG、WAF の機能を構成し、WAF ルールについてアプリケーション アーキテクトと連携する。
    • アプリケーション アーキテクト: ネットワーク セキュリティ部門と連携して、可用性を損なうことなくアプリケーションを保護するために WAF のルール セットと DDoS 構成を構築および調整する

方法はありますか。

運用を簡略化することを検討している組織には、2 つのオプションがあります。

  • 既存の機能とアーキテクチャを拡張する: 多くの組織では、既存のファイアウォール機能の使用を拡張することを選択しています。これにより、特にクラウドを初めて導入する場合に、既存の投資を活用してスキルとプロセスを統合できます。
  • ネイティブ セキュリティ制御を採用する: ますます多くの組織が、サードパーティの機能を統合する複雑さを避けるために、ネイティブ制御を使用することを希望しています。 これらの組織は一般的に、負荷分散、ユーザー定義ルート、ファイアウォールまたは WAF 自体の構成の誤りや、さまざまな技術チーム間での受け渡しの遅延を回避することを求めています。 このオプションは、コードとしてのインフラストラクチャのアプローチを採用する組織にとって魅力的です。組み込み機能はサードパーティの機能よりも簡単に自動化およびインストルメント化できるためです。

Azure ネイティブ ネットワーク セキュリティ機能に関するドキュメントは次の場所にあります。

Azure Marketplace には、多くのサードパーティ製ファイアウォール プロバイダーが含まれています。

詳細については、Azure セキュリティ ベンチマークの DDOS 保護と Web アプリケーション ファイアウォール保護に関するページを参照してください。

8.テクノロジ: ネイティブ脅威検出を統合する

"Azure システムとデータに対する攻撃の検出と対応を簡略化します。 "

何ですか?

セキュリティ運用と SIEM にネイティブの脅威検出機能を組み込むことで、脅威の検出と対応の戦略を簡略化します。

なぜでしょうか。

セキュリティ運用の目的は、環境にアクセスするアクティブな攻撃者の影響を軽減することです。 この影響は、平均応答時間 (MTTA) と修復 (MTTR) のインシデントによって測定されます。 この方法では、インシデント対応のすべての要素で精度と速度の両方が必要です。 その結果、ツールの品質とプロセス実行の効率が最も重要になります。

既存のツールとアプローチを使用して脅威の検出を向上させることは困難です。 このツールとアプローチは、オンプレミスの脅威の検出向けに設計されています。クラウド テクノロジと、その高速な変化のペースとは、違いがあるからです。 ネイティブに統合された検出は、現在の脅威とクラウド プラットフォームの変化に対応できる、クラウド プロバイダーによって維持される業界規模のソリューションを提供します。

これらのネイティブ ソリューションにより、セキュリティ運用チームは、インシデントの調査と修復に専念できます。 これらの項目に集中するため、不慣れなログ データからのアラートの作成、ツールの統合、メンテナンス タスクに時間を消費することがありません。

誰がですか?

通常は、セキュリティ運用チームによって主導されます。

  • スポンサー: この作業は通常、セキュリティ運用担当部長または同等のロールが主催します。
  • 実行: ネイティブ脅威検出の統合は共同作業であり、こちらに関するソリューションが含まれます。
    • セキュリティ運用: SIEM およびインシデント調査プロセスにアラートを統合します。 セキュリティ運用では、クラウドのアラートとその意味、ネイティブ クラウド ツールの使い方についてアナリストを教育できます。
    • インシデントの準備: クラウド インシデントを実習に組み込み、チームの準備を進めるための実習を確実に実施するようにします。
    • 脅威インテリジェンス: クラウド攻撃に関する情報を調査して統合し、チームにコンテキストとインテリジェンスの情報を提供します。
    • セキュリティ アーキテクチャ: ネイティブ ツールをセキュリティ アーキテクチャのドキュメントに統合します。
    • ポリシーと標準 : 組織全体でネイティブ ツールを有効にするための標準とポリシーを設定します。 コンプライアンスについて監視します。
    • インフラストラクチャとエンドポイントおよび中央 IT 運用: 検出を構成して有効にし、コード ソリューションとしてオートメーションとインフラストラクチャに統合します。

方法はありますか。

使用するすべてのリソースに対して Microsoft Defender for Cloud で脅威検出を有効にし、上で説明したように、各チームにこれらのリソースをプロセスに統合してもらいます。

詳細については、Azure セキュリティ ベンチマークのAzure リソースの脅威検出に関する説明を参照してください。

9.アーキテクチャ:単一のディレクトリと ID で標準化する

"複数の ID とディレクトリを処理したい人はいません。 "

何ですか?

1 つの Microsoft Entra ディレクトリで標準化します。 Azure のアプリケーションとユーザーごとに 1 つの ID で標準化できます。

Note

このベスト プラクティスは、具体的にはエンタープライズ リソースに言及しています。 パートナー アカウントの場合は、Microsoft Entra B2B を使用すると、ディレクトリ内にアカウントを作成して管理する必要がありません。 お客様または市民アカウントの場合は、Azure AD B2C を使用して管理します。

なぜでしょうか。

複数のアカウントと ID ディレクトリによって不要な摩擦が発生するため、次の毎日のワークフローで混乱が生じます。

  • 生産性の高いユーザー
  • 開発者
  • IT と ID の管理者
  • セキュリティ アナリスト
  • その他のロール

複数のアカウントとディレクトリを管理すると、セキュリティに関する不適切なやり方を促す動機が生まれます。 このやり方としては、複数のアカウント間でのパスワードの再利用などがあります。 古いアカウントや放棄されたアカウントが生じる可能性が高まり、これを攻撃者が対象にできます。

特定のアプリケーションまたはワークロードに対してカスタム LDAP ディレクトリを短時間で立ち上げる方がより簡単に見えることがありますが、この措置により、統合と管理のための作業が大幅に増えます。 この作業は、既存のエンタープライズ テナントを使用するのではなく、追加の Azure テナントまたはオンプレミスの Active Directory フォレストを設定する場合と似ています。 詳細については、シンプルさを促進するというセキュリティ原則に関するページをご覧ください。

誰がですか?

1 つの Microsoft Entra ディレクトリでの標準化は、多くの場合、複数チームによる作業になります。 この作業は、セキュリティ アーキテクチャまたはID とキー管理の担当チームによって主導されます。

  • スポンサー: この作業は通常、ID とキー管理およびセキュリティ アーキテクチャ部門が主催しますが、一部の組織では、CISO または CIO による主催が必要になる場合があります。
  • 実行: 実行は共同作業であり、次が含まれます。
    • セキュリティ アーキテクチャ: このチームは、セキュリティと IT アーキテクチャのドキュメントと図にプロセスを組み込みます。
    • ポリシーと標準: このチームは、ポリシーを文書化し、コンプライアンスを監視します。
    • ID とキーの管理または中央 IT 運用: これらのチームは、機能を有効にし、アカウントや教育などを提供して開発者をサポートすることによって、ポリシーを実装します。
    • アプリケーション開発者または中央 IT 運用: これらのチームは、アプリケーションと Azure サービス構成で ID を使用します。 責任は DevOps 導入のレベルによって異なります。

方法はありますか。

新しい "グリーンフィールド" 機能で始める実用的なアプローチを採用します。 その後、フォローアップの演習として既存のアプリケーションやサービスの "ブラウンフィールド" の課題を解消します。

  • グリーンフィールド: すべてのエンタープライズ ID で、ユーザーごとに 1 つのアカウントを持つ単一の Microsoft Entra ディレクトリを使用できるという明確なポリシーを確立して実装します。

  • ブラウンフィールド: 多くの組織では、複数のレガシ ディレクトリと ID システムを所有しています。 継続的な管理の摩擦コストがクリーンアップのための投資を超えた場合、これらのレガシ項目に対処します。 ID の管理と同期のソリューションは、これらの問題のいくつかを軽減できる一方で、セキュリティと生産性の機能については深い統合に欠けています。 これらの機能により、ユーザー、管理者、開発者にとってのシームレスなエクスペリエンスを実現できます。

ID の使用を統合するには、アプリケーション開発サイクル中の次の時点が最適なタイミングです。

  • クラウドのアプリケーションを最新化する。
  • DevOps プロセスを使用してクラウド アプリケーションを更新する。

独立性の高い事業単位の場合や規制要件がある場合、別のディレクトリとすることに合理的な理由がありますが、他のすべての状況では複数のディレクトリを使用しないようにしてください。

詳細については、Azure セキュリティ ベンチマークの Microsoft Entra の一元的な ID および認証システムに関する記事を参照してください。

重要

単一アカウント規則の唯一の例外は、特権を持つユーザー (IT 管理者とセキュリティ アナリストを含む) は、管理タスクとは別に標準ユーザー タスクのアカウントを持つことができます。

詳細については、Azure セキュリティ ベンチマークの特権アクセスに関するページを参照してください。

10. アーキテクチャ: キーではなく ID ベースのアクセスの制御を使用する

何ですか?

可能な限り、キーベースの認証ではなく Microsoft Entra ID を使用します。 たとえば、Azure サービス、アプリケーション、API などです。

なぜでしょうか。

キーベースの認証は、クラウド サービスと API に対する認証に使用できます。 ただし、キーを安全に管理する必要があり、規模が大きい場合は特に、適切に実行するのは容易ではありません。 セキュリティで保護されたキー管理は、セキュリティの専門家でない開発者やインフラストラクチャ担当者には困難であり、安全に実行できないことが多く、組織に大きなセキュリティ リスクが生じます。

ID ベースの認証の場合、これらの課題の多くを、成熟した機能で克服します。 このような機能としては、シークレットのローテーション、ライフサイクル管理、管理委任などがあります。

誰がですか?

ID ベースのアクセス制御の実装は、多くの場合、チームをまたがる作業です。 この作業は、セキュリティ アーキテクチャまたはID とキー管理の担当チームによって主導されます。

  • スポンサー: この取り組みは通常、セキュリティ アーキテクチャまたは ID とキー管理部門が主催しますが、一部の組織では CISO または CIO による主催が必要になる場合があります。
  • 実行: 共同作業であり、次が含まれます。
    • セキュリティ アーキテクチャ: このチームは、ベスト プラクティスをセキュリティと IT アーキテクチャの図とドキュメントに組み込みます。
    • ポリシーと標準: このチームは、ポリシーを文書化し、コンプライアンスを監視します。
    • ID とキーの管理または中央 IT 運用: これらのチームは、機能を有効にし、アカウントや教育などを提供して開発者をサポートすることによって、ポリシーを実装します。
    • アプリ開発者または中央 IT 運用: アプリケーションと Azure サービス構成で ID を使用します。 責任は DevOps 導入のレベルによって異なります。

方法はありますか。

ID ベースの認証を使用するための組織の基本設定と習慣を設定するには、プロセスに従ってテクノロジを有効にする必要があります。

プロセス

  1. 既定の ID ベースの認証および許容される例外を明確に示すポリシーと標準を確立します。
  2. 新しいアプローチを使用する理由、実行する必要があること、およびその方法について、開発者とインフラストラクチャ担当チームを教育します。
  3. 変更を実用的な方法で実装します。現在および将来採用される新しいグリーンフィールド機能 (新しい Azure サービスや新しいアプリケーションなど) から始めて、既存のブラウンフィールド構成のクリーンアップを行います。
  4. コンプライアンスを監視し、開発者およびインフラストラクチャ チームと共にフォローアップします。

テクノロジ

サービスやオートメーションなどの人間以外のアカウントには、マネージド ID を使用します。 Azure マネージド ID によって、Microsoft Entra 認証をサポートする Azure のサービスとリソースに対して認証を行うことができます。 認証は事前に定義されたアクセス許可規則によって有効になり、ソース コードまたは構成ファイル内でハードコーディングされた資格情報を使用せずに済みます。

マネージド ID をサポートしていないサービスの場合、Microsoft Entra ID を使用して、リソース レベルでアクセス許可が制限されたサービス プリンシパルを代わりに作成します。 証明書の資格情報を使用してサービス プリンシパルを構成し、クライアント シークレットにフォールバックする必要があります。 どちらの場合も、Azure Key Vault を Azure マネージド ID と組み合わせて使用すると、ランタイム環境 (Azure 関数など) でキー コンテナーから資格情報を取得できるようになります。

詳細については、Azure セキュリティ ベンチマークのアプリケーション ID に関する説明を参照してください。

11.アーキテクチャ:単一の統合セキュリティ戦略を確立する

"ボートが前進するには、全員が同じ方向に漕ぐ必要があります。 "

何ですか?

すべてのチームが、エンタープライズ システムとデータを可能にし、セキュリティで保護する単一の戦略に整合しているようにします。

なぜでしょうか。

複数のチームが共通の戦略に整合せず、ばらばらに作業した場合、各自のアクションが意図せずに他の人の作業を弱体化させる可能性があります。 このずれによって、全員の目標達成速度が低下する可能性があります。

チームがばらばらに作業した結果として多くの組織で常に起こっていることの一例が、資産のセグメント化です。

  • ネットワーク セキュリティ: フラット ネットワークをセグメント化するための戦略を策定します。 この戦略は、セキュリティを強化するものであり、多くの場合、物理サイト、割り当てられた IP アドレスや範囲、またはそれに類似する項目に基づいています。
  • ID チーム: 組織についての理解と知識に基づいて、グループおよび Active Directory 組織単位 (OU) に関する戦略を策定します。
  • アプリケーション チーム: これらのシステムは使用するのが難しいと感じています。 難しいのは、ビジネスの運用、目標、リスクについてのインプットと理解が制限された状態で設計されているためです。

このような制限が発生した組織では、ファイアウォールの例外についての競合がチームで頻繁に発生します。 チームが例外を承認するため、競合がセキュリティに悪影響を及ぼす可能性があります。 ビジネスに必要なアプリケーション機能のデプロイが遅くなるため、生産性がセキュリティに悪影響を与えます。

セキュリティで批判的思考を強制することで健全な摩擦を発生させることができますが、この競合で発生するのは、目標を妨げる異常な摩擦だけです。 詳細については、セキュリティ戦略ガイダンスを参照してください。

誰がですか?

  • スポンサー: 統合戦略は通常、CIO、CISO、および CTO が共同で主催します。 多くの場合、スポンサーは、一部の上位要素に対してビジネス リーダーのサポートを伴い、各チームの代表者によって支持されます。
  • 実行: 全員がセキュリティ戦略を実装する必要があります。 さまざまなチームからのデータを統合して、当事者意識、賛同、成功の可能性を高める必要があります。
    • セキュリティ アーキテクチャ: このチームはセキュリティ戦略と結果のアーキテクチャを構築する取り組みを主導します。 セキュリティ アーキテクチャでは、チームからのフィードバックを積極的に収集して、さまざまな対象ユーザーのためにプレゼンテーション、ドキュメント、図の形式で文書化します。
    • ポリシーと標準 : このチームは、適切な要素を標準およびポリシーに取り入れ、コンプライアンスを監視します。
    • すべてのテクニカル IT 担当およびセキュリティ担当チーム: これらのチームは、入力の要件を指定し、エンタープライズ戦略に整合するように実装します。
    • アプリケーションの所有者と開発者: 自分たちに適用される戦略に関するドキュメンを読み、理解します。 理想的には、各自のロールに合わせてガイダンスを調整します。

方法はありますか。

すべてのチームからのインプットと積極的な参加を含むクラウドのセキュリティ戦略を構築し、実装します。 プロセス ドキュメントの形式はさまざまですが、常に次のものが含まれます。

  • チームからの積極的なインプット: 一般に、組織内のユーザーが賛成しない戦略は失敗します。 理想的には、すべてのチームを同じ部屋に集めて、戦略を共同で構築します。 私たちがお客様と一緒に実施しているワークショップでは、多くの場合、組織が事実上縦割りで運用されていることが判明し、それらの会議で互いに初めて顔を合わせることがよくあります。 また、インクルーシブであることが必要とされることがわかりました。 一部のチームが招待されていない場合は、通常、すべての参加者が参加するまで、この会議を繰り返す必要があります。 参加しない人がいると、プロジェクトは先に進みません。
  • 文書化されていて明確に伝わる: すべてのチームは、セキュリティ戦略を認識している必要があります。 理想的には、セキュリティ戦略は、テクノロジ戦略全体におけるセキュリティ要素の 1 つです。 この戦略には、セキュリティを統合する理由、セキュリティで重要なこと、何をもってセキュリティの成功とするかなどが含まれます。 この戦略には、アプリケーションと開発の各チームに固有のガイダンスが含まれている必要があります。そうすることで、明確にまとめられたガイダンスが得られ、関係のない情報を読む必要がありません。
  • 安定していながら柔軟である: 戦略は比較的一貫した安定した状態に保つ必要がありますが、アーキテクチャとドキュメントは、明確性を高めて、クラウドの動的な特性に対応するようにしなければならない場合があります。 たとえば、使用しているサードパーティの次世代ファイアウォールから Azure Firewall に移行し、その方法に関する図やガイダンスを調整した場合でも、悪意のある外部トラフィックをフィルターで除外することは、戦略的な必須事項として一貫性を保ちます。
  • セグメント化から始める: 対処する必要がある大小の戦略の問題がありますが、どこかから始める必要があります。 エンタープライズ資産のセグメント化からセキュリティ戦略を開始します。 このセグメンテーションは、後で変更するのが難しく、ビジネスのインプットと多数の技術チームの両方を必要とする基本的な決定です。

Microsoft では、セグメント化戦略の Azure への適用に関するビデオ ガイダンスを公開しています。 企業のセグメント化とそれに合わせたネットワーク セキュリティに関するドキュメントが公開されています。

クラウド導入フレームワークには、次のことを行うチームを支援するためのガイダンスが含まれています。

詳細については、Azure セキュリティ ベンチマークのガバナンスと戦略に関する記事をご覧ください。