次の方法で共有

Azure 上の Red Hat Enterprise Linux のセキュリティに関する考慮事項

  • [アーティクル]

この記事では、Red Hat Enterprise Linux (RHEL) 環境でセキュリティを実装するための考慮事項と推奨事項について説明します。 RHEL システムのセキュリティを確保するには、複数の領域を対象とするアプローチを使用します。 セキュリティを確保するには、すべてのチームが協力してワークロードを保護する必要があります。 デプロイした製品やプラットフォームだけでは、環境のセキュリティを確保できません。

行動、管理、エンジニアリングのコンポーネントを含む厳格なプロセスを実装し、遵守してください。 Azure ランディング ゾーンに RHEL をデプロイする際には、いくつかのセキュリティ要因を評価する必要があります。 安全で回復性の高いクラウド環境を構築するには、Azure と Red Hat の両方のセキュリティ メカニズムを適用する戦略的アプローチを実装してください。

設計上の考慮事項

Azure などの環境で RHEL システムのセキュリティを確保するには、検証済みで信頼できるコンテンツから始めることが重要です。 最新のクラウド環境では、バイナリとコードはさまざまなソースから取得される可能性があります。 デプロイの最初の考慮事項は、ソフトウェア サプライ チェーンをセキュリティで保護することです。

イメージの堅牢化

イメージは、Azure Marketplace の Red Hat または Red Hat Limited (ヨーロッパ、中東、アフリカ (EMEA) リージョン) の公開プライベート製品セクションで入手できます。 Red Hat と Microsoft は、これらのイメージを検証し、ソースの整合性を確保し、RHEL オペレーティング システム インスタンスの安全な既定の構成を提供しています。

対象ワークロードに関する組織のランタイム セキュリティ要件を満たすために、これらのイメージから構築されたインスタンスを適切に構成します。 セキュリティ対策を効率化するために、Azure Marketplace から入手した Red Hat の公開イメージを使用して RHEL システムをデプロイします。 ワークロードに関するシステムおよびイメージの仕様については、Red Hat のガイダンスに従ってください。 攻撃対象領域を縮小するために、Azure 向けに最適化された最小限の RHEL イメージから始めます。 すべてのインスタンスをこの基本イメージから作成して構成する必要はありません。 堅牢化のさまざまな要件を満たすために、構成可能なコンポーネントを使用してワークロード固有のイメージを構築することをお勧めします。

GitOps のプラクティスを使用してイメージ パイプラインを開発することもできます。 これは優れた方法です。 これらのパイプラインは、構成コードとして定義された構成可能なコンポーネントを初期イメージに重ねて、ワークロード イメージを生成します。

イメージを効果的に使用するには、以下の点を考慮してください。

  • 最小権限モデルに準拠した堅牢な基本イメージを作成し、強固な基盤を提供します。

  • ソフトウェアとセキュリティ構成を重ねて再利用を促進し、標準の運用環境と DevSecOps のベスト プラクティスに従います。

  • イメージの構成モデルを使用して、テストと検証にかかる労力を減らし、メンテナンス コストを削減します。

  • 構成モデルを使用して、柔軟性を高め、新しいワークロードのデリバリーまでの時間を短縮します。

  • モデルのイメージの構築、テスト、デリバリーのプロセスを自動化します。

イメージを更新する

イメージも定期的に更新する必要があります。 エフェメラル インスタンスは通常、現在のイメージからデプロイされるため、より最新のイメージである可能性が高くなります。 ただし、長期間実行されているインスタンスは、一元化されたパッチ管理システムを使用して定期的に更新する必要があります。 この手順は、環境内のパッチ適用済みシステムの状態を調査するのに役立ちます。 デプロイのばらつきを最小限に抑えると、監視ノイズが減り、異常をより正確かつ迅速に特定できます。 このアプローチにより、自動検出と修復の成功率が向上します。

厳格なアクセス制御を維持するために、一元化されたシステムの実装を考慮します。 多くのオープンソース プロジェクトや市販のアプリケーションでは、ローカル アカウントまたはローカルにデプロイされた公開キーを使用するシンプルなデプロイ例が提供されています。 これらの例で示されている構成は安全ですが、クラウド フットプリントが拡大するにつれて、自動化を使用した場合でも、ローカライズされた構成を維持するための労力が問題になる可能性があります。 自動化の負荷は各インスタンスに対して線形に増加しますが、セキュリティ ログと監視の負荷は指数関数的に増大する可能性があります。 これらの変更により、コンピューティング、ストレージ、分析リソースに過度の負担がかかります。 一元化されたアクセス制御により、構成ポイントが減ります。これにより、自動化とログの負荷が軽減され、変更が最小限に抑えられ、リソース アクセスに対する厳格な制御を維持しながら、監査能力が簡素化されます。

ワークロードで暗号化標準とコンプライアンス ベースラインへの準拠が必要な領域では、クラウド ワークロードとの互換性を確保するために、オープンな標準をサポートする統合プラットフォーム機能の使用を考慮します。 Red Hat と Microsoft は、グローバルな標準化団体に準拠し参加しており、適切なツールを提供しています。 たとえば、個々のインスタンス全体の多くの構成ファイルには、システム サービスとアプリケーション用の暗号化構成があります。 対象ワークロード内のシステム間およびフリート全体でばらつきが発生しやすくなる可能性があります。 コンプライアンスのメトリックを定義するためには、オープンな標準の使用を考慮します。 Red Hat と Microsoft のツールでは、標準化されたファイル形式で、最新の脆弱性と構成のデータを得られます。 Red Hat は、Red Hat プラットフォーム コンポーネントについて、Red Hat 製品セキュリティ チームから最新の Open Vulnerability and Assessment Language (OVAL) フィードを提供しています。

Azure は、クラウド固有の機能を使用し、セキュリティとコンプライアンスのベスト プラクティスを維持する、独自の機会を提供しています。 Azure インフラストラクチャ内のセキュリティ機能とサービスには、以下があります。

  • VM のトラステッド起動: インスタンスの BIOS と構成をセキュリティで保護します。 VM のトラステッド起動を使用して起動プロセスをセキュリティで保護することで、VM が検証済みのコードで起動されるようにできます。

  • Azure Key Vault での Azure Disk Encryption: データを保存時に暗号化します。 保存データをセキュリティで保護するために、Key Vault で Azure Disk Encryption を使用して暗号化キーとシークレットを管理します。 Key Vault では、ボールトとマネージド ハードウェア セキュリティ モジュール (HSM) プールという 2 種類のコンテナーがサポートされています。 ソフトウェア、HSM で保護されたキー、シークレット、証明書を Vault に保存できます。

  • Microsoft Defender for Cloud: 一元化されたシステム監査を実現します。 Defender for Cloud は、統合セキュリティ管理と脅威保護のための一元化されたビューポートを提供できます。

設計の推奨事項

Azure で RHEL 環境を設計する際は、Red Hat 独自のセキュリティ機能と Azure クラウドのセキュリティ機能を活用して、堅牢で安全かつ効率的なデプロイを実現します。 既知の検証済みバイナリで堅牢化および構築したイメージから始めます。 Azure Marketplace で入手できる RHEL イメージはクラウドのパフォーマンスとセキュリティのために最適化されています。 ビジネスに特定のセキュリティ要件がある場合は、Red Hat 提供のバイナリから構築したカスタマイズされた堅牢なイメージから始めるようにしましょう。 Red Hat Satellite は、Red Hat、Microsoft、パートナーのコード、またはカスタム アプリケーション コードを維持および管理できます。 Satellite はマネージド コンテンツの資格情報と署名を通じてコードを検証できます。 RHEL はソースからディスクまでのソフトウェアの一貫性と信頼性を検証します。

Azure と Red Hat Management のツールを使用して自動化ワークフローを開発する場合、Red Hat は認定された Ansible Automation Platform コレクションの使用を推奨しています。

ワークフローでは以下が行われるようにします。

  • ベースラインおよびワークロード イメージの生成、維持、テスト。
  • エフェメラル インスタンスのテストとデプロイ。
  • パッチ サイクルのテストと永続 VM インスタンスのデリバリー。
  • 自動化パイプラインの使用。 自動化パイプラインを使用すると、管理の労力が大幅に削減され、一貫したポリシーの適用、異常検出の改善、および RHEL ランディング ゾーン全体での修復の迅速化が実現します。

Azure Compute Gallery の使用も考慮します。 組織で使用している必要なセキュリティ メカニズムをすべて使用して Red Hat イメージを構築し、その VM のイメージを作成できます。 その後、Azure 環境内のサブスクリプションおよびリージョン間でセキュリティに準拠したイメージを共有できます。 バージョン管理を使用して、VM イメージをより詳細に制御することもできます。 このアプローチは、環境で使用するコンピューティング インスタンスのセキュリティ パッチとツールを統合するのに役立ちます。

更新管理プロセスの一部として Azure Update Manager の実装を考慮します。 Update Manager は、デプロイ全体で更新プログラムを監視するために使用できる統合サービスです。 Update Manager を使用して、Azure、オンプレミス、および他のクラウドにあるマシン全体のフリートを調査します。

ID とアクセスを管理する

厳格なアクセス ポリシーを一元的に適用するために、Red Hat Identity Management (IdM) を統合します。 IdM は、信頼と OpenID Connect の統合を使用して、資格情報の同期なしで、次の機能のネイティブ Linux 実装をエンタープライズ セキュリティ モデルに統合します。

  • ロールベースのアクセス制御 (RBAC)
  • ホストベースのアクセス制御
  • 権限昇格ポリシー
  • SELinux ユーザー マッピング ポリシー
  • その他のクリティカルな Linux サービス

従来の Linux のデプロイと比べて、このアプローチには次のような利点があります。

  • 自動化の接点を減らすことによる合理化された変更管理。
  • ログと分析関連の負荷の軽減。
  • 認証監査要件への準拠。
  • ポリシーの一貫性。

IdM は、一元化された Linux セキュリティ ポリシーの管理に利点をもたらします。

Red Hat は、開発、テスト、運用環境を含むすべての RHEL ベースのインスタンスで SELinux を有効にして実行することを推奨しています。 Red Hat によって作成されたすべてのイメージとインストールでは、既定で SELinux を Enforcing モードで実行できます。 ワークロードのデプロイの設計時には、インスタンス全体またはインスタンス内の個々のサービスに対して SELinux を Permissive モードで実行できます。 その後、開発、セキュリティ、および運用チームは、アプリケーションのアクセス特性を判断し、SELinux ツールを使用して監査ログ データから、ターゲット ワークロードに適切な SELinux ポリシーを生成できます。

SELinux ポリシー生成ツールでは、標準化されたイメージ デプロイ用にコンテンツ リポジトリに含める RPM ベースのポリシー ファイルを生成できます。 開発、セキュリティ、および運用チームはパイプライン内で反復的にアーティファクトを上流にデリバリーできます。 テストで SELinux 違反が発生しないことが判明したら、SELinux 構成を Enforcing モードに設定できます。 運用環境で発生する SELinux 違反は、許容されるアプリケーションの動作からの重大な逸脱を示します。 これらの違反にフラグを立て、調査する必要があります。 SELinux を使用して、包括的な可視性とプロアクティブな脅威管理を実現します。

RHEL マシンに割り当てる RBAC ロールを定義するには、チーム内のロールと責任を理解します。 関連チームは、仮想マシン (VM) への昇格されたアクセス権を必要とする場合があります。 VM にアクセスするために、Virtual Machine Contributor、Virtual Machine Reader、および同様のロールを考慮します。 常設アクセスが不要な場合は、Just-In-Time アクセスを考慮します。 RHEL システムで Azure の認証を受ける必要がある場合は、マネージド ID を考慮します。 システム割り当てのマネージド ID は、サービス プリンシパルよりもセキュリティが高く、VM リソースに関連付けられています。 RBAC ロールに加えて、Azure 環境へのアクセスを必要とするユーザーには、条件付きアクセスを考慮します。 条件付きアクセスを使用して、場所、IP アドレス、その他の条件に基づいて Azure 環境へのユーザー アクセスを制限します。

ウイルス対策ソフトウェアを使用する

RHEL マシンに適切なウイルス対策ソフトウェアがインストールされていることを確認します。 最新の脆弱性から保護するために、Linux 上で Microsoft Defender for Endpoint をオンボードすることを考慮します。 SAP データベースをホストするために使用する RHEL マシンでは、Defender for Cloud Standard を有効にしないでください。 各 RHEL マシンとワークロードでエンドポイント保護ソフトウェアを実行できることを確認します。

シークレットを管理する

Red Hat は、可能な限りすべてのインスタンスでシステム全体の暗号化ポリシーを設定することを推奨しています。 クラウドのデプロイは多様性がその特徴です。 ワークロード チームは、特定のソリューションのニーズを満たすために、独自のライブラリ、言語、ユーティリティ、暗号化プロバイダーを選択します。 標準化、アプリケーション コンポーネントの分割、モジュール化などの技術によってシステムの多様性や複雑さを軽減できますが、アプリケーションとサービスの暗号化設定は単一のインスタンス内でも複数の箇所で個別に構成する必要があります。

新しいコンポーネントを適切に構成するには、多大な労力と、多くの場合、暗号化に関する深い知識が必要です。 暗号化ポリシーは古くなっていたり不適切に構成されたりしていると、リスクの原因になります。 システム全体の暗号化ポリシーは、コア暗号化サブシステム (Transport Layer Security (TLS)、インターネット プロトコル セキュリティ (IPSec)、ドメイン ネーム システム セキュリティ拡張機能 (DNSSEC)、Kerberos プロトコルなど) の構成を調整します。 RHEL システム全体の暗号化 DEFAULT ポリシーは、TLS v1.1 以前のバージョンなどのレガシー通信プロトコルを無効にすることで、クラス全体の脅威を排除する保守的な構成を実装します。 FUTURE ポリシーと FIPS ポリシーでは、より厳格な構成が提供されます。 カスタム ポリシーを作成することもできます。

RHEL システム監査とセキュリティ コンプライアンス ツールを統合できます。 業界標準に準拠した自動スキャンと修復に重点を置きます。

  • RHEL の監査デーモンは auditd で、中央ログ デーモンは journald です。 Azure Monitor は auditd と journald からデータを取り込んで、RHEL システムのセキュリティ イベントを監視し、Microsoft Sentinel などのセキュリティ情報およびイベント管理 (SIEM) サービスにフィードできます。

  • Defense Information Systems Agency Security Technical Implementation Guide (DISA-STIG) のコンプライアンスに準拠する必要がある RHEL システムには、Advanced Intrusion Detection Environment (AIDE) ユーティリティが必要です。 AIDE の出力を Azure に記録する必要があります。

Ansible Automation Platform を監視および統合し、重要なシステム ファイルを特定、アラート、修復します。

すべての Azure ベースの RHEL インスタンスで無料のオペレーティング システムレベルのコンポーネントを使用します。

  • コード実行ポリシーを適用する: fapolicyd デーモンを使用して、RHEL インスタンスで実行できるアプリケーションを制限します。

  • インスタンスのイングレスとエグレスのトラフィックを管理する: firewalld と Azure ネットワーク セキュリティ グループ (NSG) を使用して、VM へのノースバウンド トラフィックとサウスバウンド トラフィックを効果的に管理します。

  • 自動化を通じて構成を一元管理する: GitOps 手法を使用して、RHEL ワークロードのデプロイから Day-2 オペレーションまで一貫した構成管理を継続的に行います。

  • 政府のワークロードに対して FIPS コンプライアンス モードを実装する: 指定された RHEL インスタンスが暗号化標準に準拠するために FIPS モードで実行されるようにします。 包括的なコンプライアンス態勢のために Azure のコンプライアンス認証を使用します。

  • 常に SELinux を実行する: SELinux を Permissive モードで実行してワークロードのアクセス プロファイルを特定し、その後、RHEL VM で SELinux を Enforcing モードで実行して適切なポリシーを維持します。 SELinux により、Azure で実行されているアプリケーションとサービスの攻撃対象領域が大幅に縮小されます。

Red Hat Satellite を通じて RHEL サーバーを Red Hat Insights に登録します。 Red Hat Insights は Red Hat の問題解決データベースの分析を活用します。 Insights はこの分析を使用して、デプロイと構成の問題が運用に影響を与える前に、プロアクティブにそれらの問題を特定して修復手順を生成します。 この戦略により、セキュリティ態勢と運用効率が向上します。 すべての RHEL サブスクリプションには Insights が含まれています。 すべての RHEL クラウドベース サブスクリプションには Red Hat Satellite サブスクリプションが含まれています。 または、Cloud Access RHEL サブスクリプションと合わせて Red Hat Satellite サブスクリプションを購入することもできます。

Note

Insights は Azure の外部にテレメトリ システム情報を送信します。

ネットワークを構成する

NSG をネットワーク インターフェイス レベルまたはサブネットレベルに適用できます。 特定の要件でネットワーク インターフェイス レベルの NSG が必要でない限り、サブネット レベルをお勧めします。 このアプローチにより、ネットワーク通信の管理が簡素化されます。 アプリケーション セキュリティ グループを使用してアプリケーション通信を許可することで、サブネット間の通信が全体的にセグメント化されます。 シナリオに最適なアプローチを決定し、RHEL マシンが必要なリポジトリへのインターネット アクセスが可能かどうかを確認します。 最も厳重にロックダウンされた環境では、これらのリポジトリの URL を許可リストに追加することが必要になる場合があります。 プライベート エンドポイントを使用すると、Azure リソースが既定で受信できるトラフィックは Azure ネットワークから送信されるトラフィックのみに制限されます。これには、Azure ゲートウェイを介したオンプレミスからの接続も含まれます。

SIEM または SOAR ツールを実装する

RHEL システムのセキュリティ オーケストレーション、自動化、および応答 (SOAR) ツールまたは SIEM ツールとして、Microsoft Sentinel を考慮します。 Microsoft Sentinel は AI を使用して、システムへの脅威の検出方法を調整します。 Runbook を使用して、攻撃への対応を自動化できます。 Microsoft Sentinel を使用して、プロアクティブな脅威の検出、脅威のハンティング、脅威への対応を行います。

機密コンピューティングを考慮する

RHEL には、特定の RHEL オペレーティング システム オプション用の機密イメージが用意されています。 機密コンピューティングのユース ケースを考慮してください。

次のステップ