次の方法で共有

リソースの強化に関する推奨事項

  • [アーティクル]

以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に適用されます。

SE:08 余分な面領域を減らし、強化した構成で攻撃者のコストを増やすことで、すべてのワークロード コンポーネントを強化します。

このガイドでは、ワークロード内でローカライズされた制御を開発し、繰り返し攻撃に耐えられるように維持することで、リソースを強化するための推奨事項について説明します。

セキュリティ強化は、意図的な自己保存の対応です。 そのゴールは、攻撃面を減らし、他の領域において攻撃者のコストを増やすことで、悪意のあるアクターが脆弱性を悪用する機会を制限することです。 ワークロードを保護するには、セキュリティのベスト プラクティスおよび構成を実装します。

セキュリティ強化は継続的なプロセスであり、進化する脅威と脆弱性への継続的な監視と適応が必要です。

定義

相談 定義
セキュリティ強化 余分なリソースを削除する、または構成を調整することで、攻撃面を減らす方法。
特権アクセス ワークステーション (PAW) 機密性の高いタスクを実行するために使用される、セキュリティで保護された専用のマシン。これにより、侵害のリスクが軽減されます。
セキュリティで保護された管理ワークステーション (SAW) 重大な影響があるアカウントで使用される特殊な PAW。
面領域 脆弱性を含むワークロードの論理占有領域。

主要な設計戦略

セキュリティ強化は、リソースであれプロセスであれ、コンポーネント レベルで制御を強化する、高度にローカライズされた対応です。 各コンポーネントのセキュリティを強化すると、ワークロードの総合的なセキュリティ保証が向上します。

セキュリティ強化では、ワークロードの機能は考慮されません。また、脅威を検出したり、自動スキャンを実行したりすることはありません。 セキュリティ強化では、侵害の想定と多層防御の考え方を使用した、構成のチューニングに重点を置きます。 そのゴールは、攻撃者がシステムの制御を得るのを困難にすることです。 強化によって、ワークロードまたはその操作の意図した実用性が変更されてはなりません。

ワークロード資産のインベントリを構築する

強化プロセスの最初の手順は、すべてのハードウェア、ソフトウェア、データ資産の包括的なインベントリを収集することです。 新しい資産を追加し、使用停止された資産を削除することで、インベントリ レコードを最新に保ちます。 インベントリ内のすべての資産について、次のベスト プラクティスを検討してください。

  • 占有領域を減らす: 余分な面領域を削除するか、スコープを小さくします。 狙われやすいターゲット、またはコストが低い常套の攻撃ベクトル (更新プログラムが適用されていないソフトウェアの悪用、ブルート フォース攻撃など) を排除します。 運用環境デプロイの前に、ソース ツリーから ID、ビルド コンポーネント、その他の必須ではない資産をクリーンアップする必要があります。

  • 構成を微調整する: 残りの面領域を評価して強化します。 リソースが強化されると、攻撃者が使用する、試行済みでテスト済みの方法が成功しなくなります。 これにより、攻撃者は高度なまたは未テストの攻撃方法を習得して使用することを余儀なくされ、コストが増加します。

  • 防御を維持する: 継続的な脅威検出を実行することで保護対策を維持し、強化の取り組みの信頼性を長期的に確保します。

また、次の要因も考慮してください。

信頼できるソース。 強化対応の一部には、ソフトウェア サプライ チェーンが含まれます。 このガイダンスでは、すべてのコンポーネントが信頼できるソースから取得されることを前提としています。 組織は、サード パーティ ベンダーから調達したソフトウェアを承認する必要があります。 この承認は、オペレーティング システム、イメージ、その他のサード パーティ ツールのソースに適用されます。 信頼できるリソースがない場合、強化は、信頼できないソースに対するセキュリティ保証の、無限の浪費になるおそれがあります。

サプライ チェーンのセキュリティに関する推奨事項については、「開発ライフサイクルをセキュリティで保護するための推奨事項」を参照してください。

トレーニング。 強化は特殊なスキルです。 それは体系的であり、高いレベルのコンピテンシーが必要です。 コンポーネントの機能と、変更がそのコンポーネントに与える影響を理解する必要があります。 チーム メンバーは、業界の専門家やプラットフォームからのガイダンスを識別し、不確実なソースからのガイダンスと区別できる必要があります。 チーム メンバーを教育して、セキュリティに対応したカルチャを作成します。 チームが確実にセキュリティのベスト プラクティスに習熟し、潜在的な脅威を認識して、インシデント後の振り返りから学ぶようにします。

ドキュメント。 強化の要件、決定事項、定義された方法を文書化して公開します。 透明性のために、それらの要件からの例外または逸脱も文書化します。

強化は面倒な場合がありますが、文書化する必要がある重要なセキュリティ対応です。 まずコア コンポーネントを強化し、次に自動化されたプロセスや人手によるプロセスなどの他の領域に拡張して、潜在的なギャップを強化します。 変更に細心の注意を払います。 たとえば、既定値を変更するとシステムの安定性に影響する場合があるため、既定の設定を無効にする手順が必要です。 たとえ置き換える構成が既定値と同じ場合でも、それを定義する必要があります。 次のセクションでは、強化の一般的なターゲットについて説明します。 ワークロードの主要な設計領域を評価し、主要な戦略に従ってコンポーネント レベルで強化します。

ネットワーク コンポーネントを強化する

ネットワークをセグメントに分割する: 重要な資産と機密データを安全性の低い資産から分離することで、攻撃者による横移動を減らします。 それらのセグメント内では、"既定で拒否" のアプローチを適用します。 正当な場合にのみ、許可リストへのアクセスを追加します。

アクティブに使用されていないポートとプロトコルを無効にする: たとえば、Azure App Service 上では、FTP 経由でデプロイする必要がない場合は、それを無効にすることができます。 または、内部ネットワーク経由で管理操作を実行する場合は、インターネットからの管理アクセスを無効にすることができます。

レガシ プロトコルを削除または無効にする: 攻撃者は、以前のバージョンを使用するシステムを悪用します。 Azure 検出サービスを使用してログを確認し、プロトコルの使用を判断します。 システムの機能が中断される可能性があるため、プロトコルを削除するのは困難な場合があります。 運用中断のリスクを軽減するために、実装前にすべての変更をテストします。

パブリック IP (PIP) アドレスを高リスクの資産として扱う: アクセスが容易で、世界中に広がっているためです。 露出を減らすには、ワークロードへの不要なインターネット アクセスを削除します。 Azure Front Door などの Microsoft サービスが提供する共有パブリック IP アドレスを使用します。 これらのサービスはインターネットに接続するように設計されており、許可されていないプロトコルへのアクセスをブロックします。 このようなサービスの多くは、ネットワーク エッジで受信要求に対して初期チェックを実行します。 専用の PIP では、そのセキュリティの側面を管理して、ポートを許可またはブロックし、受信要求をスキャンしてその有効性を確認するのは、ユーザーの責任となります。

レイヤー 7 サービスを追加することでアクセスを制限する: インターネットに接続するアプリケーションの場合、無効なトラフィックをフィルター処理できます。 分散型サービス拒否 (DDoS) の保護を適用し、Web アプリケーション ファイアウォールを備え、トラフィックがアプリケーション層に到達する前にエッジで保護を提供するネイティブ サービスについて確認します。

ドメイン ネーム システム (DNS) の強化は、もう 1 つのネットワーク セキュリティ プラクティスです。 DNS インフラストラクチがセキュリティで保護されていることを保証するには、信頼できる DNS リゾルバーを使用することをお勧めします。 DNS リゾルバーからの情報を検証し、セキュリティの追加レイヤーを提供するには、可能であれば、機密性の高い DNS ゾーンに対して DNS セキュリティ プロトコルを使用します。 DNS キャッシュ ポイズニング、DDoS 攻撃、増幅攻撃などの攻撃を防ぐには、クエリ レート制限、応答レート制限、DNS Cookie など、他の DNS 関連のセキュリティ制御を確認します。

ID アクセス制御を強化する

使用されていないまたは既定のアカウントを削除する: 使用されていない認証と認可の方法を無効にします。

レガシの認証方法を無効にする: 攻撃ベクトルであることが多いためです。 以前のプロトコルは、多くの場合、アカウント ロックアウトなどの攻撃対策が不足しています。 認証要件を、Microsoft Entra ID などの ID プロバイダー (IdP) に外部化します。

重複した ID を作成するよりもフェデレーションを優先する: ID が侵害された場合、それが一元管理されていれば、アクセスを取り消すのがより簡単になります。

プラットフォームの機能を理解する: 認証と認可を強化するためです。 多要素認証、パスワードレス認証、条件付きアクセス、Microsoft Entra ID が ID を検証するために提供するその他の機能を活用して、アクセス制御を強化します。 サインイン イベントに対する保護を追加し、攻撃者が要求を行えるスコープを減らすことができます。

マネージド ID とワークロード ID を使用する: 可能な限り資格情報は使用しません。 資格情報は漏洩する可能性があります。 詳細については、「アプリケーション シークレットを保護するための推奨事項」を参照してください。

管理プロセスには、最低特権のアプローチを使用する: 不要なロールの割り当てを削除し、定期的な Microsoft Entra アクセス レビューを実行します。 ロールの割り当ての説明を使用して、正当な理由の書面証跡を保持します。これは監査に不可欠です。

クラウド リソース構成を強化する

前述のネットワークと ID の強化に関する推奨事項は、個々のクラウド サービスに適用されます。 ネットワークの場合は、サービス レベルのファイアウォールに特に注意を払い、その受信規則を評価します。

使用されていない機能を検出して無効にする: 使用されていないデータ プレーン アクセスや製品機能など、他のコンポーネントがカバーしている可能性があるものです。 たとえば、App Service では、FTP デプロイ、リモート デバッグ、その他の機能などを提供する Kudu がサポートされています。 それらの機能が必要ない場合はオフにします。

常に Azure ロードマップとワークロード ロードマップに対応する: Azure サービスが提供するパッチとバージョン管理の更新プログラムを適用します。 プラットフォームによって提供される更新プログラムを許可し、自動更新チャネルをサブスクライブします。

リスク: クラウド リソースには、多くの場合、許容量の要件があります。または、"サポート対象" と見なされるためには、文書化された構成で実行する必要があります。 送信トラフィックを積極的にブロックするなどの一部の強化手法により、たとえサービスが正常に動作している場合でも、そのサービスがサポート対象の構成の範囲外になる可能性があります。 プラットフォームの各クラウド リソースのランタイム要件を理解し、そのリソースのサポートを確実に維持します。

コード資産を強化する

アプリケーションが誤って情報を漏洩させる可能性がある領域を評価します。 たとえば、ユーザー情報を取得する API があるとします。 要求に有効なユーザー ID が含まれており、アプリケーションから 403 エラーが返される場合があります。 しかし、無効な顧客 ID を使用すると、その要求には 404 エラーが返されます。 すると、ユーザー ID に関する情報が事実上漏洩することになります。

さらに微妙なケースがあるかもしれません。 たとえば、有効なユーザー ID の応答待機時間は、無効な顧客 ID よりも長くなります。

次の領域において、アプリケーション強化の実装を検討してください。

  • 入力の検証とサニタイズ: すべてのユーザー入力を検証してサニタイズすることで、SQL インジェクションやクロスサイト スクリプティング (XSS) などのインジェクション攻撃を防ぎます。 入力検証ライブラリとフレームワークを使用して、入力のサニタイズを自動化します。

  • セッション管理: セキュリティで保護されたセッション管理手法を使用して、セッション ID とトークンを盗難またはセッション固定化攻撃から保護します。 セッション タイムアウトを実装し、機密性の高いアクションに対して再認証を適用します。

  • エラー管理: 攻撃者への機密情報の公開を最小限に抑えるために、カスタム エラー処理を実装します。 エラーを安全にログに記録し、これらのログで疑わしいアクティビティを監視します。

  • HTTP セキュリティ ヘッダー: コンテンツ セキュリティ ポリシー (CSP)、X-Content-Type-Options、X-Frame-Options など、HTTP 応答内のセキュリティ ヘッダーを使用して、一般的な Web の脆弱性を軽減します。

  • API セキュリティ: 適切な認証と認可メカニズムを使用して、API をセキュリティで保護します。 セキュリティをさらに強化するには、API エンドポイントにレート制限、要求検証、アクセス制御を実装します。

アプリケーションを開発およびメンテナンスする際は、安全なコーディング プラクティスに従います。 コード レビューを定期的に実施し、アプリケーションの脆弱性をスキャンします。 詳細については、「開発ライフサイクルをセキュリティで保護するための推奨事項」を参照してください。

管理操作を強化する

また、他のランタイム以外のリソースも強化します。 たとえば、すべての資産のインベントリを取得し、パイプラインから使用されていない資産を削除することで、ビルド操作の占有領域を削減します。 次に、信頼できるソースによって発行されたタスクをプルし、検証されたタスクのみを実行します。

Microsoft がホストする、またはセルフホステッドのビルド エージェントが必要かどうかを判断します。 セルフホステッドのビルド エージェントには追加の管理が必要であり、強化する必要があります。

監視の観点から、潜在的な侵害についてログを確認するためのプロセスを実装します。 アクセス ログに基づいて、アクセス制御規則を定期的に確認および更新します。 中央チームと協力し、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) ログを分析して、異常を検出します。

特権管理操作に PAW または SAW を要求することを検討してください。 PAW と SAW は、セキュリティ上の大きな利点を提供する強化された物理デバイスですが、その実装には慎重な計画と管理が必要です。 詳細については、「特権アクセスの一部としてデバイスをセキュリティで保護する」を参照してください。

Azure ファシリテーション

Microsoft Defender for Cloud には、いくつかの強化機能が用意されています。

Center for Internet Security (CIS) は、Azure Marketplace において強化されたイメージを提供しています。

Azure VM Image Builder を使用して、強化された OS イメージの反復可能なプロセスを構築できます。 Common Base Linux-Mariner は、セキュリティ標準と業界認定に従って Microsoft が開発した、強化された Linux ディストリビューションです。 これを Azure インフラストラクチャ製品と共に使用して、ワークロードの実装を構築できます。

例

次の手順は、オペレーティング システムを強化する方法の例です。

  1. 占有領域を減らす: イメージ内の不要なコンポーネントを削除します。 必要なものだけをインストールします。

  2. 構成を微調整する: 使用されていないアカウントを無効にします。 オペレーティング システムの既定の構成には、セキュリティ グループにリンクされている余分なアカウントがあります。 それらのアカウントを使用しない場合は、無効にするか、システムから削除します。 余分な ID は、サーバーへのアクセスを得るために使用できる脅威ベクトルです。

    ファイル システムへの不要なアクセスを無効にします。 ファイル システムを暗号化し、ID とネットワークのアクセス制御を微調整します。

    必要なものだけを実行します。 既定で実行されるアプリケーションとサービスをブロックします。 ワークロード機能に必要なアプリケーションとサービスのみを承認します。

  3. 防御を維持する: 既知の脆弱性を軽減するために、オペレーティング システムコンポーネントを最新のセキュリティ更新プログラムとパッチで定期的に更新します。

CIS ベンチマーク

セキュリティ チェックリスト

レコメンデーションの完全なセットを参照してください。

セキュリティ チェックリスト