リソースのセキュリティ強化に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。

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

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

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

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

定義

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

主要な設計戦略

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

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

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

  • フットプリントを減らします。 余分なサーフェス領域を削除するか、スコープを小さくします。 パッチが適用されていないソフトウェアの悪用やブルート フォース攻撃など、簡単なターゲット、または安価で確立された攻撃ベクトルを排除します。 運用デプロイの前に、ソース ツリーから ID、ビルド コンポーネント、およびその他の必要でない資産をクリーンする必要があります。

  • 構成を微調整します。 残りの表面積を評価して締めます。 リソースが強化されると、攻撃者が使用する試行およびテストされた方法は成功しなくなります。 これにより、攻撃者は高度な攻撃方法またはテストされていない攻撃方法を取得して使用することが強制され、コストが増加します。

  • 防御を維持する。 継続的な脅威検出を実行して保護対策を維持し、強化作業が時間の経過と同時に確実に確実に行われるようにします。

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

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

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

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

ドキュメント。 セキュリティ強化の要件、決定事項、および定義されたメソッドを文書化して公開します。 透明性を確保するために、例外やそれらの要件からの 逸脱も文書化 します。

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

ネットワーク

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

アクティブに使用されていないポートとプロトコルを無効にします。 たとえば、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 が侵害された場合は、一元管理されている場合にアクセスを取り消す方が簡単です。

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

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

管理プロセスには、最小限の特権のアプローチを使用します。 不要なロールの割り当てを削除し、定期的なMicrosoft Entraアクセス レビューを実行します。 ロールの割り当ての説明を使用して、正当な理由の記録を保持します。これは監査にとって重要です。

クラウド リソース

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

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

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

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

アプリケーション

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

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

次の領域でアプリケーションのセキュリティ強化を実装することを検討してください。

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

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

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

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

組織の配置

クラウド導入フレームワーク for Azure では、一元化された ID およびアクセス管理機能の作成に関するガイダンスが提供されます。 詳細については、「 Azure ID とアクセス管理の設計領域」を参照してください。

CIS ベンチマーク

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

推奨事項の完全なセットを参照してください。

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