以下の Azure Well-Architected フレームワーク セキュリティ チェックリストの推奨事項に適用されます。
| SE:08 | 不要な露出面を減らし、構成を厳密にして攻撃者のコストを増大させるようにして、すべてのワークロード コンポーネントを強化します。 |
|---|
このガイドでは、ワークロード内でローカライズされた制御を開発し、繰り返し攻撃に耐えられるように維持することで、リソースを強化するための推奨事項について説明します。
セキュリティ強化は、意図的な自己保存の対応です。 そのゴールは、攻撃面を減らし、他の領域において攻撃者のコストを増やすことで、悪意のあるアクターが脆弱性を悪用する機会を制限することです。 ワークロードを保護するには、セキュリティのベスト プラクティスおよび構成を実装します。
セキュリティ強化は継続的なプロセスであり、進化する脅威と脆弱性への継続的な監視と適応が必要です。
用語
| 期間 | 定義 |
|---|---|
| セキュリティ強化 | 余分なリソースを削除する、または構成を調整することで、攻撃面を減らす方法。 |
| 特権アクセス ワークステーション (PAW) | 機密性の高いタスクを実行するために使用される、セキュリティで保護された専用のマシン。これにより、侵害のリスクが軽減されます。 |
| セキュリティで保護された管理ワークステーション (SAW) | 重要な影響を持つアカウントで使用される特殊な PAW。 |
| 表面積 | 脆弱性を含むワークロードの論理フットプリント。 |
セキュリティ強化は、リソースであれプロセスであれ、コンポーネント レベルで制御を強化する、高度にローカライズされた対応です。 各コンポーネントのセキュリティを強化すると、ワークロードの総合的なセキュリティ保証が向上します。
セキュリティ強化では、ワークロードの機能は考慮されません。また、脅威を検出したり、自動スキャンを実行したりすることはありません。 セキュリティ強化では、侵害の想定と多層防御の考え方を使用した、構成のチューニングに重点を置きます。 そのゴールは、攻撃者がシステムの制御を得るのを困難にすることです。 強化によって、ワークロードまたはその操作の意図した実用性が変更されてはなりません。
ワークロード資産のインベントリを構築する
セキュリティ強化プロセスの最初の手順は、すべてのハードウェア、ソフトウェア、およびデータ資産の完全なインベントリを収集することです。 新しい資産を追加し、使用停止された資産を削除することで、インベントリ レコードを最新に保ちます。 インベントリ内のすべての資産について、次のベスト プラクティスを検討してください。
占有領域を減らす: 余分な面領域を削除するか、スコープを小さくします。 狙われやすいターゲット、またはコストが低い常套の攻撃ベクトル (更新プログラムが適用されていないソフトウェアの悪用、ブルート フォース攻撃など) を排除します。 運用環境デプロイの前に、ソース ツリーから ID、ビルド コンポーネント、その他の必須ではない資産をクリーンアップする必要があります。
リスク: リソースの使用停止、ID またはロールの割り当ての削除、プロトコルのサポートの削減、データの削除は、重要な機能が誤って失われる可能性があります。 安全な使用停止プロセスを使用して、このリスクを軽減します。
構成を微調整する。 残りの面領域を評価して強化します。 リソースが強化されると、攻撃者が使用する、試行済みでテスト済みの方法が成功しなくなります。 これにより、攻撃者は高度なまたは未テストの攻撃方法を習得して使用することを余儀なくされ、コストが増加します。
防御を維持する: 継続的な脅威検出を実行して保護対策を維持し、強化作業が時間の経過とともに確実に行われるようにします。
また、次の要因も考慮してください。
ソースを確認します。 強化対応の一部には、ソフトウェア サプライ チェーンが含まれます。 このガイダンスでは、すべてのコンポーネントが信頼できるソースから取得されることを前提としています。 組織は、サード パーティ ベンダーから調達したソフトウェアを承認する必要があります。 この承認は、オペレーティング システム、イメージ、その他のサード パーティ ツールのソースに適用されます。 信頼できるリソースがない場合、強化は、信頼できないソースに対するセキュリティ保証の、無限の浪費になるおそれがあります。
サプライ チェーンのセキュリティに関する推奨事項については、開発ライフサイクルをセキュリティで保護するための推奨事項を参照してください。
チームをトレーニングします。 強化は特殊なスキルです。 それは体系的であり、高いレベルのコンピテンシーが必要です。 コンポーネントの機能と、変更がそのコンポーネントに与える影響を理解する必要があります。 チーム メンバーは、業界の専門家やプラットフォームからのガイダンスを識別し、不確実なソースからのガイダンスと区別できる必要があります。 チーム メンバーを教育して、セキュリティに対応したカルチャを作成します。 チームが確実にセキュリティのベスト プラクティスに習熟し、潜在的な脅威を認識して、インシデント後の振り返りから学ぶようにします。
決定事項を文書化します。 強化の要件、決定事項、定義された方法を文書化して公開します。 透明性のために、それらの要件からの例外または逸脱も文書化します。
強化は面倒な場合がありますが、文書化する必要がある重要なセキュリティ対応です。 まずコア コンポーネントを強化し、次に自動化されたプロセスや人手によるプロセスなどの他の領域に拡張して、潜在的なギャップを強化します。 変更に細心の注意を払います。 たとえば、既定値を変更するとシステムの安定性に影響する場合があるため、既定の設定を無効にする手順が必要です。 たとえ置き換える構成が既定値と同じ場合でも、それを定義する必要があります。
不要なものを削除する
攻撃者は、不要な構成を持つシステムを悪用します。 不要なものを削除し、レガシーなものは廃止します。
使用されていない機能やデータ プレーン アクセスを検出して無効にすることで、他のコンポーネントがカバーしている可能性がある製品機能を特定できます。 たとえば、App Service では、FTP デプロイ、リモート デバッグ、その他の機能などを提供する Kudu がサポートされています。 それらの機能が必要ない場合はオフにします。
アクティブに使用されていないポートとプロトコルを無効にする: たとえば、Azure App Service 上では、FTP 経由でデプロイする必要がない場合は、それを無効にすることができます。 または、内部ネットワーク経由で管理操作を実行する場合は、インターネットからの管理アクセスを無効にすることができます。
レガシ プロトコルを削除または無効にする: 攻撃者は、以前のバージョンを使用するシステムを悪用します。 Azure 検出サービスを使用してログを確認し、プロトコルの使用を判断します。 システムの機能が中断される可能性があるため、プロトコルを削除するのは困難な場合があります。 露出を最小限に抑えるために、レガシ プロトコルを分離することを検討してください。 運用中断のリスクを軽減するために、実装前にすべての変更をテストします。
使用されていないまたは既定のアカウントを削除する: 使用されていない認証と認可の方法を無効にします。
レガシ認証方法は頻繁な攻撃ベクトルであるため、無効にします。 古いプロトコルでは、多くの場合、アカウントロックアウトなどの対策が欠けています。 認証要件を、Microsoft Entra ID などの ID プロバイダー (IdP) に外部化します。
インターネットへの露出を減らす
パブリック インターネットから到達できるワークロードの量を最小限に抑えます。
パブリック IP (PIP) アドレスを高リスクの資産として扱う: アクセスが容易で、世界中に広がっているためです。 露出を減らすには、ワークロードへの不要なインターネット アクセスを削除します。 Azure Front Doorなど、Microsoft サービスの共有パブリック IP アドレスを使用します。 これらのサービスはインターネットに接続するように設計されており、許可されていないプロトコルへのアクセスをブロックします。 このようなサービスの多くは、ネットワーク エッジで受信要求に対して初期チェックを実行します。 専用の PIP を使用すると、ポートの許可やブロック、受信要求をスキャンして有効性を確認するなど、セキュリティの側面を管理する責任があります。
インターネットに接続するアプリケーション用のレイヤー 7 サービスを追加して、 無効なトラフィックをフィルター処理します。 分散型サービス拒否 (DDoS) の保護を適用し、Web アプリケーション ファイアウォールを備え、トラフィックがアプリケーション層に到達する前にエッジで保護を提供するネイティブ サービスについて確認します。
信頼された DNS リゾルバーを使用して 、DNS インフラストラクチャを強化します。 DNS リゾルバーからの情報を検証し、セキュリティの追加レイヤーを提供するには、可能であれば、機密性の高い DNS ゾーンに対して DNS セキュリティ プロトコルを使用します。 DNS キャッシュ ポイズニング、DDoS 攻撃、増幅攻撃などの攻撃を防ぐには、クエリ レート制限、応答レート制限、DNS Cookie など、他の DNS 関連のセキュリティ制御を確認します。
プライベート エンドポイントを使用して、パブリック IP なしでAzure サービスに安全な接続を提供します。 プライベート エンドポイントは、パブリック インターネットへの露出を減らします。
必要な内容へのアクセスを制限する
各コンポーネントに必要なアクセス権のみを付与し、既定では他のすべてを拒否します。
ネットワークをセグメントに分割する: 重要な資産と機密データを安全性の低い資産から分離することで、攻撃者による横移動を減らします。 それらのセグメント内では、既定で拒否 のアプローチを適用します。 正当な場合にのみ、許可リストへのアクセスを追加します。
ネットワーク セキュリティ グループ (NSG) を使用して、Azure仮想ネットワーク内のAzure リソースとの間のトラフィックをフィルター処理します。 NSG には、送信元または送信先の IP アドレス、ポート、プロトコルに基づいて、受信および送信のネットワーク トラフィックを許可または拒否するセキュリティ規則が含まれています。
サービス レベルのファイアウォールを評価します。 受信規則と送信規則を確認し、アクセス要件に合わせて強化します。
管理プロセスには、最小特権のアプローチとロールの分離を使用します。 不要なロールの割り当てを削除し、定期的な Microsoft Entra アクセス レビューを実行します。 1 つの ID に複数のロールを割り当てないでください。 ロールの割り当ての説明を使用して、正当な理由の書面証跡を保持します。これは監査に不可欠です。
重複する ID よりもフェデレーションを優先します。 ID が侵害された場合は、一元管理されている場合にアクセスを取り消す方が簡単です。 特権 ID を持つフェデレーション アカウントの作成は避けてください。
マネージド ID とワークロード ID を使用する: 可能な限り資格情報は使用しません。 資格情報は漏洩する可能性があります。 詳細については、アプリケーション シークレットを保護するための推奨事項を参照してください。
プラットフォーム機能を活用する
独自のコントロールを構築する代わりに、組み込みのプラットフォーム セキュリティ機能を使用します。
プラットフォームの機能を理解する: 認証と認可を強化するためです。 多要素認証、パスワードレス認証、条件付きアクセス、および ID を検証するその他のMicrosoft Entra ID機能を使用して、アクセス制御を強化します。 これらの機能により、サインイン イベントに関する保護が強化され、攻撃者が要求を行うことができる範囲が縮小されます。
大規模なセキュリティ強化を適用します。 Azure Policyを使用してリソース全体にセキュリティ強化要件を適用および監査し、新しいリソースが自動的に標準を継承できるようにします。
パッチ適用と更新プログラムを最新の状態に保つ
常にAzure ロードマップとワークロード ロードマップを注視する。 Azure サービスが提供するパッチとバージョン管理の更新プログラムを適用します。 プラットフォームによって提供される更新プログラムを許可し、自動更新チャネルをサブスクライブします。
リスク: 多くの場合、クラウド リソースには許容量の要件があります。また、 サポート対象と見なされるためには、文書化された構成で実行する必要があります。 送信トラフィックを積極的にブロックするなどの一部の強化手法により、たとえサービスが正常に動作している場合でも、そのサービスがサポート対象の構成の範囲外になる可能性があります。 プラットフォームの各クラウド リソースのランタイム要件を理解し、そのリソースのサポートを確実に維持します。
データ資産を強化する
適切な資産を強化できるように、最初にデータを分類します。 分類では、侵害が最も害を及ぼす可能性がある強化作業に重点を置いています。 詳細については、「 データ分類の推奨事項」を参照してください。
暗号化を使用して、保存データと転送中のデータを保護します。 攻撃者が基になるストレージにアクセスしたり、トラフィックを傍受したりした場合に読み取れないようにデータを暗号化します。 詳細については、「 データ暗号化の推奨事項」を参照してください。 すべての通信に最小 TLS バージョンを適用し、弱いバージョンと暗号スイートを無効にします。
コード資産を強化する
アプリケーションが誤って情報を漏洩させる可能性がある領域を評価します。 たとえば、ユーザー情報を取得する 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 がホストする、またはセルフホステッドのビルド エージェントが必要かどうかを判断します。 セルフホステッドのビルド エージェントには追加の管理が必要であり、強化する必要があります。
特権管理操作に PAW または SAW を要求することを検討してください。 PAW と SAW は、セキュリティ上の大きな利点を提供する強化された物理デバイスですが、その実装には慎重な計画と管理が必要です。 詳細については、「特権アクセスストーリーの一部としてデバイスを保護する」を参照してください。
ハードニングを監視し維持する
継続的な監視と脅威の検出により、リソースを可視化できます。 Cloud Security Posture Management (CSPM) などのツールを使用して、構成の誤り、未承認のアクセス、セキュリティで保護されていないインターフェイスを検出します。
潜在的な侵害のログを確認するプロセスを実装します。 アクセス ログに基づいて、アクセス制御規則を定期的に確認および更新します。 中央チームと協力し、セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) ログを分析して、異常を検出します。
セキュリティ強化を確認します。 CIS ベンチマークなどのセキュリティ ベースラインまたは業界ベンチマークに対してリソースを定期的にスキャンして、構成の誤差を検出し、セキュリティ強化がまだ実施されていることを確認します。
Azure ファシリテーション
Microsoft Defender for Cloud には、いくつかの強化機能が用意されています。
- サーバーハードニング
- アダプティブネットワークの強化
- Docker ホストのセキュリティ強化機能
Center for Internet Security (CIS) は、Azure Marketplace において強化されたイメージを提供しています。
Azure VM Image Builder を使用して、強化された OS イメージの反復可能なプロセスを構築できます。 Common Base Linux-Mariner は、セキュリティ標準と業界認定に従って Microsoft が開発した、強化された Linux ディストリビューションです。 これを Azure インフラストラクチャ製品と共に使用して、ワークロードの実装を構築できます。
Azure ポリシーは、Azure リソース全体に強化要件を適用するのに役立ちます。 組み込みのポリシーを使用するか、カスタム ポリシーを作成して、リソースが組織のセキュリティ標準に準拠していることを確認できます。
プライベート エンドポイントでは、Azure Virtual Network (VNet) のプライベート IP アドレスを使用して、Azure Private Linkを利用するサービスに安全に接続します。 プライベート エンドポイントを使用すると、パブリック インターネットへの露出を減らし、Azure リソースのセキュリティを強化できます。
例
次の手順は、オペレーティング システムを強化する方法の例です。
占有領域を減らす: イメージ内の不要なコンポーネントを削除します。 必要なものだけをインストールします。
構成を微調整する。 使用されていないアカウントを無効にします。 オペレーティング システムの既定の構成には、セキュリティ グループにリンクされている余分なアカウントがあります。 それらのアカウントを使用しない場合は、無効にするか、システムから削除します。 余分な ID は、サーバーへのアクセスを得るために使用できる脅威ベクトルです。
ファイル システムへの不要なアクセスを無効にします。 ファイル システムを暗号化し、ID とネットワークのアクセス制御を微調整します。
必要なものだけを実行します。 既定で実行されるアプリケーションとサービスをブロックします。 ワークロード機能に必要なアプリケーションとサービスのみを承認します。
防御を維持する: 既知の脆弱性を軽減するために、オペレーティング システムコンポーネントを最新のセキュリティ更新プログラムとパッチで定期的に更新します。
関連リンク
- アダプティブネットワークの強化
- アプリケーション シークレットの保護に関するレコメンデーション
- 開発ライフサイクルをセキュリティで保護するための推奨事項
- データ分類に関する推奨事項
- データ暗号化に関する推奨事項
- 特権アクセスの一部としてデバイスを保護する
- サーバーハードニング
- Docker ホストのセキュリティ強化機能
コミュニティ リンク
CIS ベンチマーク
セキュリティ チェックリスト
レコメンデーションの完全なセットを参照してください。