Menu Close

セキュリティーの強化

Red Hat Enterprise Linux 9

Red Hat Enterprise Linux 9 の保護

概要

本書は、ユーザーおよび管理者が、ローカルおよびリモートの侵入、悪用、および悪意のある行為からワークステーションおよびサーバーを保護するプロセスおよびプラクティスを学ぶのに利用できます。本ガイドでは、Red Hat Enterprise Linux を対象としていますが、概念および手法はすべての Linux システムに適用できます。データセンター、勤務先、および自宅で安全なコンピューティング環境を構築するのに必要な計画およびツールを詳細に説明します。管理上の適切な知識、警戒体制、およびツールを備えることで、Linux を実行しているシステムの機能をフルに活用して、大概の一般的な侵入や悪用の手法からシステムを保護できます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバックの提供

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。

  • 特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 インストール時の RHEL の保護

セキュリティーへの対応は、Red Hat Enterprise Linux をインストールする前にすでに始まっています。最初からシステムのセキュリティーを設定することで、追加のセキュリティー設定を実装することがより簡単になります。

1.1. BIOS および UEFI のセキュリティー

BIOS (もしくは BIOS に相当するもの) およびブートローダーをパスワードで保護することで、システムに物理的にアクセス可能な未承認ユーザーがリムーバブルメディアを使用して起動したり、シングルユーザーモードで root 権限を取得することを防ぐことができます。このような攻撃に対するセキュリティー対策は、ワークステーションの情報の機密性とマシンの場所によって異なります。

たとえば、見本市で使用されていて機密情報を含んでいないマシンでは、このような攻撃を防ぐことが重要ではないかもしれません。しかし、同じ見本市で、企業ネットワークに対して暗号化されていない SSH 秘密鍵のある従業員のノートパソコンが、誰の監視下にもなく置かれていた場合は、重大なセキュリティー侵害につながり、その影響は企業全体に及ぶ可能性があります。

一方で、ワークステーションが権限のあるユーザーもしくは信頼できるユーザーのみがアクセスできる場所に置かれてるのであれば、BIOS もしくはブートローダーの安全確保は必要ない可能性もあります。

1.1.1. BIOS パスワード

コンピューターの BIOS をパスワードで保護する主な 2 つの理由を以下に示します。[1]オプションを追加します

  1. BIOS 設定の変更を防止する - 侵入者が BIOS にアクセスした場合は、CD-ROM やフラッシュドライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシングルユーザーモードに入ることが可能になり、システムで任意のプロセスを開始したり、機密性の高いデータをコピーできるようになってしまいます。
  2. システムの起動を防止する - BIOS の中には起動プロセスをパスワードで保護できるものもあります。これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められます。

BIOS パスワードの設定方法はコンピューターメーカーで異なるため、具体的な方法はコンピューターのマニュアルを参照してください。

BIOS パスワードを忘れた場合は、マザーボードのジャンパーでリセットするか、CMOS バッテリーを外します。このため、可能な場合はコンピューターのケースをロックすることが推奨されます。ただし、CMOS バッテリーを外す前にコンピューターもしくはマザーボードのマニュアルを参照してください。

1.1.2. 非 BIOS ベースシステムのセキュリティー

その他のシステムやアーキテクチャーでは、異なるプログラムを使用して x86 システムの BIOS とほぼ同等の低レベルのタスクを実行します。UEFI (Unified Extensible Firmware Interface) シェルなどがこの例になります。

BIOS のようなプログラムをパスワード保護する方法は、メーカーにお問い合わせください。

1.2. ディスクのパーティション設定

Red Hat は、/boot//home/tmp、および /var/tmp/ の各ディレクトリーに別々のパーティションを作成することを推奨します。

/boot
このパーティションは、システムの起動時にシステムが最初に読み込むパーティションです。Red Hat Enterprise Linux 9 でシステムを起動するのに使用するブートローダーとカーネルイメージはこのパーティションに保存されます。このパーティションは暗号化しないでください。このパーティションが /` に含まれており、そのパーティションが暗号化されているなどの理由で利用できなくなると、システムを起動できなくなります。
/home
ユーザーデータ (/home) が別のパーティションではなく / に保存されていると、このパーティションが満杯になり、オペレーティングシステムが不安定になる可能性があります。また、システムを、Red Hat Enterprise Linux 9 の次のバージョンにアップグレードする際に、/home パーティションにデータを保存できると、このデータはインストール時に上書きされないため、アップグレードが非常に簡単になります。root パーティション (/) が破損すると、データが完全に失われます。したがって、パーティションを分けることが、データ損失に対する保護につながります。また、このパーティションを、頻繁にバックアップを作成する対象にすることも可能です。
/tmp および /var/tmp/
/tmp ディレクトリーおよび /var/tmp/ ディレクトリーは、どちらも長期保存の必要がないデータを保存するのに使用されます。しかし、このいずれかのディレクトリーでデータがあふれると、ストレージ領域がすべて使用されてしまう可能性があります。このディレクトリーは / に置かれているため、こうした状態が発生すると、システムが不安定になり、クラッシュする可能性があります。そのため、このディレクトリーは個別のパーティションに移動することが推奨されます。
注記

インストールプロセス時に、パーティションを暗号化するオプションがあります。パスフレーズを入力する必要があります。これは、パーティションのデータを保護するのに使用されるバルク暗号鍵を解除する鍵として使用されます。

1.3. インストールプロセス時のネットワーク接続の制限

Red Hat Enterprise Linux 9 をインストールする際に使用するインストールメディアは、特定のタイミングで作成されたスナップショットです。そのため、セキュリティー修正が最新のものではなく、このインストールメディアで設定するシステムが公開されてから修正された特定の問題に対して安全性に欠ける場合があります。

脆弱性が含まれる可能性のあるオペレーティングシステムをインストールする場合には、必ず、公開レベルを、必要最小限のネットワークゾーンに限定してください。最も安全な選択肢は、インストールプロセス時にマシンをネットワークから切断した状態にする「ネットワークなし」のゾーンです。インターネット接続からのリスクが最も高く、一方で LAN またはイントラネット接続で十分な場合もあります。セキュリティーのベストプラクティスに従い、ネットワークから Red Hat Enterprise Linux 9 をインストールする場合は、お使いのリポジトリーに最も近いゾーンを選択するようにしてください。

1.4. 必要なパッケージの最小限のインストール

コンピューターの各ソフトウェアには脆弱性が潜んでいる可能性があるため、実際に使用するパッケージのみをインストールすることがベストプラクティスになります。インストールを DVD から行う場合は、インストールしたいパッケージのみを選択するようにします。その他のパッケージが必要になる場合は、後でいつでもシステムに追加できます。

1.5. インストール後の手順

以下は、Red Hat Enterprise Linux 9 のインストール直後に実行する必要があるセキュリティー関連の手順です。

  • システムを更新します。root で以下のコマンドを実行します。

    # dnf update
  • ファイアウォールサービスである firewalld は、Red Hat Enterprise Linux のインストールで自動的に有効になりますが、キックスタート設定などで明示的に無効になっている場合があります。このような場合は、ファイアウォールを再度有効にすることが推奨されます。

    firewalld を開始するには、root で次のコマンドを実行します。

    # systemctl start firewalld
    # systemctl enable firewalld
  • セキュリティーを強化するために、不要なサービスは無効にしてください。たとえば、使用中のコンピューターにプリンターがインストールされていなければ、以下のコマンドを使用して cups サービスを無効にします。

    # systemctl disable cups

    アクティブなサービスを確認するには、次のコマンドを実行します。

    $ systemctl list-units | grep service


[1] システム BIOS はメーカーによって異なるため、どちらのタイプのパスワード保護もサポートしていないものもあれば、一方のタイプはサポートしているが他方はサポートしていないものもあります。

第2章 FIPS モードでのシステムのインストール

FIPS (Federal Information Processing Standard) 140-3 による暗号化モジュールの自己チェックを有効にするには、FIPS モードで RHEL 9 を操作する必要があります。

そのためには、以下を行います。

  • FIPS モードでのインストールの開始
  • インストール後に FIPS モードにシステムを切り替えます。

デプロイ済みのシステムへの変換に関連するシステムコンプライアンスの暗号鍵資料の再生成や再評価を回避するために、Red Hat は FIPS モードでインストールを開始することを推奨します。

注記

RHEL 9 の暗号化モジュールは、FIPS 140-3 の要件に対して認定されていません。

2.1. FIPS (Federal Information Processing Standard)

連邦情報処理標準 (FIPS) 140-3 は、U.S により開発されたコンピューターセキュリティー標準です。暗号化モジュールの品質を検証する政府および業界の作業グループ。NIST Computer Security Resource Center で公式の FIPS 公開を参照してください。

FIPS 140-3 標準は、暗号化ツールがアルゴリズムを正しく実装できるようにします。そのメカニズムの 1 つがランタイムのセルフチェックです。FIPS 標準の詳細とその他の仕様については、FIPS PUB 140-3 の完全な FIPS 140-3 規格を参照してください。

コンプライアンスの要件については、「Red Hat Government Standards」ページを参照してください。

2.2. FIPS モードが有効になっているシステムのインストール

FIPS (Federal Information Processing Standard) Publication 140-3 による暗号モジュールの自己チェックを有効にするには、システムのインストール時に FIPS モードを有効にします。

重要

Red Hat は、後で FIPS モードを有効にするのではなく、FIPS モードを有効にして RHEL をインストールすることを推奨します。インストール時に FIPS モードを有効にすると、システムは FIPS で承認されるアルゴリズムと継続的な監視テストですべてのキーを生成するようになります。

手順

  • システムのインストール時に fips=1 オプションをカーネルコマンドラインに追加します。

    ソフトウェアの選択段階で、サードパーティーのソフトウェアをインストールしないでください。

インストール後に、システムは FIPS モードで自動的に起動します。

検証

  • システムが起動したら、FIPS モードが有効になっていることを確認します。

    $ fips-mode-setup --check
    FIPS mode is enabled.

関連情報

2.3. 関連情報

第3章 システム全体の暗号化ポリシーの使用

システム全体の暗号化ポリシーは、コア暗号化サブシステムを構成するシステムコンポーネントで、TLS、IPSec、SSH、DNSSec、および Kerberos の各プロトコルに対応します。これにより、管理者が選択できる小規模セットのポリシーを提供します。

3.1. システム全体の暗号化ポリシー

システム全体のポリシーを設定すると、RHEL のアプリケーションはそのポリシーに従い、ポリシーを満たしていないアルゴリズムやプロトコルを使用するように明示的に要求されない限り、その使用を拒否します。つまり、システムが提供した設定で実行する際に、デフォルトのアプリケーションの挙動にポリシーを適用しますが、必要な場合は上書きできます。

RHEL 9 には、以下の定義済みポリシーが含まれています。

DEFAULT

デフォルトのシステム全体の暗号化ポリシーレベルで、現在の脅威モデルに対して安全なものです。TLS プロトコルの 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは長さが 2048 ビット以上であれば許容されます。

LEGACY

このポリシーにより、Red Hat Enterprise Linux 6 以前との最大の互換性が保証されます。攻撃対象範囲が広がるため、安全性が低くなります。SHA-1 は、TLS ハッシュ、署名、およびアルゴリズムとして使用できます。CBC モードの暗号は、SSH と併用できます。GnuTLS を使用するアプリケーションは、SHA-1 で署名した証明書を許可します。TLS プロトコルの 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは長さが 2048 ビット以上であれば許容されます。

FUTURE

近い将来の攻撃に耐えられると考えられている保守的なセキュリティーレベルです。このレベルでは、DNSSec または HMAC で SHA-1 を使用することができません。SHA2-224 ハッシュおよび SHA3-224 ハッシュは無効になります。128 ビット暗号は無効になります。CBC モードの暗号は、Kerberos を除き無効になります。TLS プロトコルの 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは、ビット長が 3072 以上だと許可されます。

FIPS

FIPS140-2 要件に準拠するポリシールールです。これは、fips-mode-setup ツールの内部で使用され、RHEL システムを FIPS モードに切り替えます。

Red Hat は常に、レガシーポリシーの使用時以外、全ライブラリーにセキュアなデフォルト値が提供されるように、全ポリシーレベルを調節します。レガシープロファイルではセキュアなデフォルト値が提供されませんが、簡単に悪用できるアルゴリズムは含まれません。このため、提供されたポリシーで有効なアルゴリズムのセットまたは許容可能な鍵サイズは、Red Hat Enterprise Linux の存続期間中に変更する可能性があります。

このような変更は、新しいセキュリティー標準や新しいセキュリティー調査を反映しています。Red Hat Enterprise Linux の有効期間中、特定のシステムとの相互運用性を確保する必要がある場合は、そのシステムと相互作用するコンポーネントの暗号化ポリシーから除外し、カスタムポリシーを使用して特定のアルゴリズムを再度有効にする必要があります。

重要

カスタマーポータル API の証明書が使用する暗号化キーは FUTURE のシステム全体の暗号化ポリシーが定義する要件を満たさないので、現時点で redhat-support-tool ユーティリティーは、このポリシーレベルでは機能しません。

この問題を回避するには、カスタマーポータル API への接続中に DEFAULT 暗号化ポリシーを使用します。

注記

ポリシーレベルで許可されていると記載されている特定のアルゴリズムと暗号は、アプリケーションがそれに対応している場合に限り使用できます。

暗号化ポリシーを管理するツール

現在のシステム全体の暗号化ポリシーを表示または変更するには、update-crypto-policies ツールを使用します。以下に例を示します。

$ update-crypto-policies --show
DEFAULT
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

暗号化ポリシーの変更を確実に適用するには、システムを再起動します。

安全ではない暗号スイートおよびプロトコルを削除した、強力な暗号デフォルト

以下の一覧は、Red Hat Enterprise Linux 9 のコア暗号ライブラリーから削除された暗号スイートとプロトコルを示しています。このアプリケーションはソースには存在しないか、またはビルド時にサポートを無効にしているため、アプリケーションは使用できません。

  • DES (RHEL 7 以降)
  • すべてのエクスポートグレードの暗号化スイート (RHEL 7 以降)
  • 署名内の MD5 (RHEL 7 以降)
  • SSLv2 (RHEL 7 以降)
  • SSLv3 (RHEL 8 以降)
  • 224 ビットより小さいすべての ECC 曲線 (RHEL 6 以降)
  • すべてのバイナリーフィールドの ECC 曲線 (RHEL 6 以降)

すべてのポリシーレベルで無効になっているアルゴリズム

以下のアルゴリズムは、RHEL 9 に同梱される LEGACYDEFAULTFUTURE、および FIPS の暗号化ポリシーでは無効になっています。これらはカスタム暗号化ポリシーの適用、または個々のアプリケーションの明示的な設定によってのみ有効にできます。有効になる設定はサポートされていないと見なされます。

  • バージョン 1.2 より古い TLS (RHEL 9 以降、以前では RHEL 8 の 1.0 未満)
  • バージョン 1.2 より古い DTLS (RHEL 9 以降、RHEL 8 では 1.0 未満)
  • パラメーターが 2048 ビット未満の DH (RHEL 9 以降、RHEL 8 では 1024 ビット未満)
  • 鍵サイズ (2048 ビット 未満) の RSA (RHEL 9 以降、RHEL 8 では 1024 ビット未満)
  • DSA (RHEL 9 以降、RHEL 8 では 1024 ビット未満)
  • 3DES (RHEL 9 以降)
  • RC4 (RHEL 9 以降)
  • FFDHE-1024 (RHEL 9 以降)
  • DHE-DSS (RHEL 9 以降)
  • Camellia (RHEL 9 以降)
  • ARIA
  • IKEv1 (RHEL 8 以降)

暗号ポリシーレベルで有効なアルゴリズム

以下の表は、選択したアルゴリズムに関する、4 つの暗号ポリシーのすべてのレベルの比較を示しています。

 LEGACYDEFAULTFIPSFUTURE

IKEv1

いいえ

いいえ

いいえ

いいえ

3DES

いいえ

いいえ

いいえ

いいえ

RC4

いいえ

いいえ

いいえ

いいえ

DH

最低 2048 ビット

最低 2048 ビット

最低 2048 ビット

最低 3072 ビット

RSA

最低 2048 ビット

最低 2048 ビット

最低 2048 ビット

最低 3072 ビット

DSA

いいえ

いいえ

いいえ

いいえ

TLS v1.1 以前

いいえ

いいえ

いいえ

いいえ

TLS v1.2 以降

はい

はい

はい

はい

SHA-1 デジタル署名および証明書に

はい

いいえ

いいえ

いいえ

CBC モード暗号

はい

いいえ[a]

いいえ[b]

いいえ[c]

256 ビットより小さい鍵を持つ対称暗号

はい

はい

はい

いいえ

[a] SSH で CBC 暗号が無効になっている
[b] CBC 暗号は、Kerberos を除くすべてのプロトコルで無効になります。
[c] CBC 暗号は、Kerberos を除くすべてのプロトコルで無効になります。

関連情報

  • update-crypto-policies(8) の man ページ

3.2. システム全体の暗号化ポリシーを、以前のリリースと互換性のあるモードに切り替え

Red Hat Enterprise Linux 9 におけるデフォルトのシステム全体の暗号化ポリシーでは、現在は古くて安全ではないプロトコルは許可されません。Red Hat Enterprise Linux 6 および以前のリリースとの互換性を必要とする環境では、セキュアではない LEGACY ポリシーレベルを利用できます。

警告

LEGACY ポリシーレベルに設定すると、システムおよびアプリケーションの安全性が低下します。

手順

  1. システム全体の暗号化ポリシーを LEGACY レベルに切り替えるには、root で以下のコマンドを実行します。

    # update-crypto-policies --set LEGACY
    Setting system policy to LEGACY

関連情報

  • 利用可能な暗号化ポリシーのレベルは、man ページの update-crypto-policies(8) を参照してください。
  • カスタム暗号化ポリシーの定義については、man ページの update-crypto-policies (8)Custom Policies セクションと、crypto-policies(7)Crypto Policy Definition Format セクションを参照してください。

3.3. FIPS モードへのシステムの切り替え

システム全体の暗号化ポリシーには、連邦情報処理規格 (FIPS) 公開文書 140-3 の要件に準拠した暗号化モジュールのセルフチェックを有効にするポリシーレベルが含まれます。FIPS モードを有効または無効にする fips-mode-setup ツールは、内部的に FIPS のシステム全体の暗号化ポリシーレベルを使用します。

重要

Red Hat は、後で FIPS モードを有効にするのではなく、FIPS モードを有効にして Red Hat Enterprise Linux 9 をインストールすることを推奨します。インストール時に FIPS モードを有効にすると、システムは FIPS で承認されるアルゴリズムと継続的な監視テストですべてのキーを生成するようになります。

注記

RHEL 9 の暗号化モジュールは、FIPS 140-3 の要件に対して認定されていません。

手順

  1. システムを FIPS モードに切り替えるには、以下のコマンドを実行します。

    # fips-mode-setup --enable
    Kernel initramdisks are being regenerated. This might take some time.
    Setting system policy to FIPS
    Note: System-wide crypto policies are applied on application start-up.
    It is recommended to restart the system for the change of policies
    to fully take place.
    FIPS mode will be enabled.
    Please reboot the system for the setting to take effect.
  2. システムを再起動して、カーネルを FIPS モードに切り替えます。

    # reboot

検証

  1. システムが再起動したら、FIPS モードの現在の状態を確認できます。

    # fips-mode-setup --check
    FIPS mode is enabled.

関連情報

3.4. コンテナーでの FIPS モードの有効化

FIPS モードが有効になっているシステムでは、podman ユーティリティーはコンテナーを FIPS モードに自動的に設定します。FIPS モードではないシステムでは、後で 1 つのコマンドを使用して、コンテナーを FIPS モードに切り替えることができます。

注記

コンテナーで fips-mode-setup コマンドが正しく機能せず、このシナリオでこのコマンドを使用して FIPS モードを有効にしたり確認することができません。

注記

RHEL 9 の暗号化モジュールは、FIPS 140-3 の要件に対して認定されていません。

前提条件

  • ホストシステムが FIPS モードである必要があります。

手順

  • FIPS モードに切り替えるコンテナーで、以下のコマンドを使用します。

    # mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends

3.5. FIPS 140-3 に準拠していない暗号化を使用している RHEL アプリケーションのリスト

Red Hat は、FIPS 140-3 などの関連する暗号化認定をすべて渡し、RHEL システム全体の暗号化ポリシーに従うことが保証されているため、Red Hat は、コア暗号化コンポーネントからライブラリーを使用することを推奨します。

コア暗号化コンポーネントの概要、そのコンポーネントの選択方法、オペレーティングシステムへの統合方法、ハードウェアセキュリティーモジュールおよびスマートカードのサポート方法、暗号化による認定の適用方法の概要は、RHEL コア暗号化コンポーネント を参照してください。

表3.1 FIPS 140-3 に準拠していない暗号化を使用している RHEL 8 アプリケーションのリスト

アプリケーションDetails

Bacula

CRAM-MD5 認証プロトコルを実装します。

Cyrus SASL

SCRAM-SHA-1 認証方式を使用します。

Dovecot

SCRAM-SHA-1 を使用します。

Emacs

SCRAM-SHA-1 を使用します。

FreeRADIUS

認証プロトコルに MD5 および SHA-1 を使用します。

Ghostscript

ドキュメントを暗号化および復号化するためのカスタムの cryptogtaphy 実装 (MD5、RC4、SHA-2、AES)

GRUB2

SHA-1 を必要とするレガシーファームウェアプロトコルをサポートし、libgcrypt ライブラリーを含みます。

ipxe

TLS スタックを実装します。

Kerberos

SHA-1 (Windows との相互運用性) のサポートを維持します。

lasso

lasso_wsse_username_token_derive_key () 鍵導出関数 (KDF) は SHA-1 を使用します。

MariaDB、MariaDB コネクター

mysql_native_password 認証プラグインは SHA-1 を使用します。

MySQL

mysql_native_password は SHA-1 を使用します。

OpenIPMI

RAKP-HMAC-MD5 認証方式は、FIPS の使用が承認されておらず、FIPS モードでは機能しません。

OVMF (UEFI ファームウェア)、Edk2、shim

完全な暗号スタック (OpenSSL ライブラリーの埋め込みコピー)

perl-CPAN

MD5 認証をダイジェストします。

perl-Digest-HMAC、perl-Digest-SHA

HMAC、HMAC-SHA1、HMAC-MD5、SHA-1、SHA-224 などを使用します。

perl-Mail-DKIM

Signer クラスは、デフォルトで RSA-SHA1 アルゴリズムを使用します。

PKCS #12 ファイル処理(OpenSSL、GnuTLS、NSS、Firefox、Java)

ファイル全体の HMAC の計算に使用される Key Derivation Function(KDF)は FIPS で承認されないため、PKCS #12 はすべて FIPS に準拠していません。そのため、FIPS コンプライアンスの目的で、PKCS #12 ファイルはプレーンテキストとして考慮されます。キートランスポートの目的で、FIPS で承認される暗号化スキームを使用して PKCS #12(.p12)ファイルをラップします。

Poppler

元の PDF (MD5、RC4、SHA-1 など) に存在する場合は、許可されていないアルゴリズムに基づいて署名、パスワード、および暗号化を使用して PDF を保存できます。

PostgreSQL

KDF は SHA-1 を使用します。

QAT エンジン

暗号化プリミティブの混在ハードウェアおよびソフトウェア実装 (RSA、EC、DH、AES、…​)

Ruby

安全でないライブラリー関数 MD5 および SHA-1 を提供します。

Samba

RC4 および DES (Windows との相互運用性) のサポートを維持します。

Syslinux

BIOS パスワードは SHA-1 を使用します。

Unbound

DNS 仕様では、DNSSEC リゾルバーが検証のために DNSKEY レコードで SHA-1 ベースのアルゴリズムを使用する必要があります。

Valgrind

AES、SHA ハッシュ。[a]

[a] ARM 上の AES-NI、SHA-1 および SHA-2 などのソフトウェアハードウェアオフロード操作を再実装します。

3.6. システム全体の暗号化ポリシーに従わないようにアプリケーションを除外

アプリケーションで使用される暗号化関連の設定をカスタマイズする必要がある場合は、サポートされる暗号スイートとプロトコルをアプリケーションで直接設定することが推奨されます。

/etc/crypto-policies/back-ends ディレクトリーからアプリケーション関連のシンボリックリンクを削除することもできます。カスタマイズした暗号化設定に置き換えることもできます。この設定により、除外されたバックエンドを使用するアプリケーションに対するシステム全体の暗号化ポリシーが使用できなくなります。この修正は、Red Hat ではサポートされていません。

3.6.1. システム全体の暗号化ポリシーを除外する例

wget

wget ネットワークダウンローダーで使用される暗号化設定をカスタマイズするには、--secure-protocol オプションおよび --ciphers オプションを使用します。以下に例を示します。

$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" https://example.com

詳細は、wget(1) man ページの HTTPS (SSL/TLS) Options のセクションを参照してください。

curl

curl ツールで使用する暗号を指定するには、--ciphers オプションを使用して、その値に、コロンで区切った暗号化のリストを指定します。以下に例を示します。

$ curl https://example.com --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'

詳細は、man ページの curl(1) を参照してください。

Firefox

Web ブラウザーの Firefox でシステム全体の暗号化ポリシーをオプトアウトできない場合でも、Firefox の設定エディターで、対応している暗号と TLS バージョンをさらに詳細に制限できます。アドレスバーに about:config と入力し、必要に応じて security.tls.version.min の値を変更します。たとえば、security.tls.version.min1 に設定すると、最低でも TLS 1.0 が必要になり、security.tls.version.min 2 が TLS 1.1 になります。

OpenSSH

OpenSSH クライアントのシステム全体の暗号化ポリシーをオプトアウトするには、次のいずれかのタスクを実行します。

  • 指定のユーザーの場合は、~/.ssh/config ファイルのユーザー固有の設定でグローバルの ssh_config を上書きします。
  • システム全体の場合は、辞書学的に 50-redhat.conf ファイルよりも前に来るように、50 未満の 2 桁の接頭辞と、.conf の接尾辞で /etc/ssh/ssh_config.d/ ディレクトリーにあるドロップイン設定ファイルに暗号ポリシーを指定します (例: 49-crypto-policy-override.conf など)。

詳細は、ssh_config(5) の man ページを参照してください。

Libreswan

詳細は、『Securing networks』の「Configuring IPsec connections that opt out of the system-wide crypto policies」を参照してください。

関連情報

  • update-crypto-policies(8) の man ページ

3.7. サブポリシーを使用したシステム全体の暗号化ポリシーのカスタマイズ

この手順を使用して、有効な暗号化アルゴリズムまたはプロトコルのセットを調整します。

既存のシステム全体の暗号化ポリシーの上にカスタムサブポリシーを適用するか、そのようなポリシーを最初から定義することができます。

スコープが設定されたポリシーの概念により、バックエンドごとに異なるアルゴリズムセットを有効にできます。各設定ディレクティブは、特定のプロトコル、ライブラリー、またはサービスに限定できます。

また、ディレクティブでは、ワイルドカードを使用して複数の値を指定する場合にアスタリスクを使用できます。

/etc/crypto-policies/state/CURRENT.pol ファイルには、ワイルドカード拡張後に現在適用されているシステム全体の暗号化ポリシーの設定がすべて表示されます。暗号化ポリシーをより厳格にするには、/usr/share/crypto-policies/policies/FUTURE.pol ファイルに記載されている値の使用を検討してください。

手順

  1. /etc/crypto-policies/policies/modules/ ディレクトリーをチェックアウトします。

    # cd /etc/crypto-policies/policies/modules/
  2. 調整用のサブポリシーを作成します。次に例を示します。

    # touch MYCRYPTO-1.pmod
    # touch SCOPES-AND-WILDCARDS.pmod
    重要

    ポリシーモジュールのファイル名には大文字を使用します。

  3. 任意のテキストエディターでポリシーモジュールを開き、システム全体の暗号化ポリシーを変更するオプションを挿入します。次に例を示します。

    # vi MYCRYPTO-1.pmod
    min_rsa_size = 3072
    hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512
    # vi SCOPES-AND-WILDCARDS.pmod
    # Disable the AES-128 cipher, all modes
    cipher = -AES-128-*
    
    # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
    cipher@TLS = -CHACHA20-POLY1305
    
    # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
    group@SSH = FFDHE-1024+
    
    # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
    cipher@SSH = -*-CBC
    
    # Allow the AES-256-CBC cipher in applications using libssh
    cipher@libssh = AES-256-CBC+
  4. 変更をモジュールファイルに保存します。
  5. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

    # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS
  6. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

    # reboot

検証

  • /etc/crypto-policies/state/CURRENT.pol ファイルに変更が含まれていることを確認します。以下に例を示します。

    $ cat /etc/crypto-policies/state/CURRENT.pol | grep rsa_size
    min_rsa_size = 3072

関連情報

  • update-crypto-policies(8) man ページの Custom Policies セクション
  • crypto-policies(7) man ページの Crypto Policy Definition Format セクション
  • Red Hat ブログ記事「How to customize crypto policies in RHEL 8.2

3.8. SHA-1 を再度有効に

署名を作成および検証するための SHA-1 アルゴリズムの使用は、DEFAULT 暗号化ポリシーで制限されています。シナリオで既存またはサードパーティーの暗号署名を検証するために SHA-1 を使用する必要がある場合は、RHEL 9 がデフォルトで提供する SHA1 サブポリシーを適用することで有効にできます。システムのセキュリティーが弱くなることに注意してください。

前提条件

  • このシステムは、DEFAULT システム全体の暗号化ポリシーを使用します。

手順

  1. SHA1 サブポリシーを DEFAULT 暗号化ポリシーに適用します。

    # update-crypto-policies --set DEFAULT:SHA1
    Setting system policy to DEFAULT:SHA1
    Note: System-wide crypto policies are applied on application start-up.
    It is recommended to restart the system for the change of policies
    to fully take place.
  2. システムを再起動します。

    # reboot

検証

  • 現在の暗号化ポリシーを表示します。

    # update-crypto-policies --show
    DEFAULT:SHA1
重要

update-crypto-policies --set LEGACY コマンドを使用して LEGACY 暗号化ポリシーに切り替えると、署名に対して SHA-1 も有効になります。ただし、LEGACY 暗号化ポリシーは、他の弱い暗号化アルゴリズムも有効にすることで、システムをはるかに脆弱にします。この回避策は、SHA-1 署名以外のレガシー暗号化アルゴリズムを有効にする必要があるシナリオでのみ使用してください。

3.9. システム全体のカスタム暗号化ポリシーの作成および設定

以下の手順は、完全なポリシーファイルでシステム全体の暗号化ポリシーをカスタマイズする方法を示しています。

手順

  1. カスタマイズのポリシーファイルを作成します。

    # cd /etc/crypto-policies/policies/
    # touch MYPOLICY.pol

    または、定義されている 4 つのポリシーレベルのいずれかをコピーします。

    # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol
  2. 必要に応じて、テキストエディターでファイルを編集します。以下のようにしてカスタム暗号化ポリシーを使用します。

    # vi /etc/crypto-policies/policies/MYPOLICY.pol
  3. システム全体の暗号化ポリシーをカスタムレベルに切り替えます。

    # update-crypto-policies --set MYPOLICY
  4. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

    # reboot

関連情報

  • update-crypto-policies (8) の man ページの Custom Policies セクションと、crypto-policies(7)Crypto Policy Definition Format セクションを参照してください。
  • Red Hat ブログ記事 How to customize crypto policies in RHEL

第4章 システム間でのカスタム暗号化ポリシーの設定

管理者は、Cryptographic Policies RHEL システムロール を使用して、Ansible Core パッケージを使用し、多くの異なるシステムでカスタム暗号化ポリシーを迅速かつ一貫して設定できます。

4.1. Cryptographic Policies システムロール変数とファクト

Cryptographic Policies システムロール Playbook では、設定および制限に合わせて、暗号化ポリシー設定ファイルのパラメーターを定義できます。

変数を設定しない場合には、システムロールではシステムが設定されず、ファクトのみが報告されます。

Cryptographic Policies システムロールの一部の変数

crypto_policies_policy
管理対象ノードにシステムロールを適用する暗号化ポリシーを決定します。異なる暗号化ポリシーの詳細は、「システム全体の暗号化ポリシー」を参照してください。
crypto_policies_reload
yes に設定すると、暗号化ポリシーの適用後に、影響を受けるサービス (現在 ipsecバインド、および sshd サービス) でリロードされます。デフォルトは yes です。
crypto_policies_reboot_ok
yes に設定されており、システムロールで暗号化ポリシーを変更した後に再起動が必要な場合には、crypto_policies_reboot_requiredyes に設定します。デフォルトは no です。

Cryptographic Policies システムロールにより設定されるファクト

crypto_policies_active
現在選択されているポリシーを一覧表示します。
crypto_policies_available_policies
システムで利用可能なすべてのポリシーを表示します。
crypto_policies_available_subpolicies
システムで利用可能なすべてのサブポリシーを表示します。

4.2. Cryptographic Policies システムロールを使用したカスタム暗号化ポリシーの設定

Cryptographic Policies システムロールを使用すると、単一のコントロールノードから多数の管理対象ノードを設定できます。

前提条件

  • Crypto Policies システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • Ansible Core が他のシステムを設定するシステムである制御ノードへのアクセスと許可。

    コントロールノードに、

    • ansible-core パッケージおよび rhel-system-roles パッケージがインストールされている。
重要

RHEL 8.0-8.5 は、Ansible に基づく自動化用に Ansible Engine 2.9 が含まれる別の Ansible リポジトリーへのアクセスを提供していました。Ansible Engine には、ansibleansible-playbookdockerpodman などのコネクター、多くのプラグインやモジュールなどのコマンドラインユーティリティーが含まれます。Ansible Engine の取得およびインストール方法の詳細は、ナレッジベースの記事「 How to download and install Red Hat Ansible Engine 」を参照してください。

RHEL 8.6 および 9.0 では、Ansible Core が導入されました( ansible-core パッケージとして提供)。これには、Ansible コマンドラインユーティリティー、コマンド、およびビルトイン Ansible プラグインの小規模なセットが含まれます。RHEL は AppStream リポジトリーを介してこのパッケージを提供し、サポート範囲が限定されています。詳細は、ナレッジベース の記事「RHEL 9 および RHEL 8.6 以降の AppStream リポジトリーに含まれる Ansible Core パッケージのサポート範囲」を参照し てください。

  • 管理対象ノードが記載されているインベントリーファイルがある。

手順

  1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

    ---
    - hosts: all
      tasks:
      - name: Configure crypto policies
        include_role:
          name: rhel-system-roles.crypto_policies
        vars:
          - crypto_policies_policy: FUTURE
          - crypto_policies_reboot_ok: true

    FUTURE の値は、任意の暗号化ポリシー (例: DEFAULTLEGACY、および FIPS:OSPP) に置き換えることができます。

    crypto_policies_reboot_ok: true 変数を設定すると、システムロールで暗号化ポリシーを変更した後にシステムが再起動されます。

    詳細は「Crypto Policies システムロール変数およびファクト」を参照してください。

  2. オプション:Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

検証

  1. コントロールノードで (例: verify_playbook.yml) という名前の別の Playbook を作成します。

    - hosts: all
      tasks:
     - name: Verify active crypto policy
       include_role:
         name: rhel-system-roles.crypto_policies
    
     - debug:
         var: crypto_policies_active

    この Playbook では、システムの設定は変更されず、管理対象ノードのアクティブなポリシーだけを報告します。

  2. 同じインベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file verify_playbook.yml
    
    TASK [debug] **************************
    ok: [host] => {
        "crypto_policies_active": "FUTURE"
    }

    "crypto_policies_active": 変数は、管理対象ノードでアクティブなポリシーを表示します。

4.3. 関連情報

第5章 PKCS #11 で暗号化ハードウェアを使用するようにアプリケーションを設定

スマートカードや、エンドユーザー認証用の暗号化トークン、サーバーアプリケーション用のハードウェアセキュリティーモジュール (HSM) など、専用の暗号化デバイスで秘密情報の一部を分離することで、セキュリティー層が追加されます。RHEL では、PKCS #11 API を使用した暗号化ハードウェアへの対応がアプリケーション間で統一され、暗号ハードウェアでの秘密の分離が複雑なタスクではなくなりました。

5.1. PKCS #11 による暗号化ハードウェアへの対応

PKCS #11 (Public-Key Cryptography Standard) は、暗号化情報を保持する暗号化デバイスに、アプリケーションプログラミングインターフェース (API) を定義し、暗号化機能を実行します。このデバイスはトークンと呼ばれ、ハードウェアまたはソフトウェアの形式で実装できます。

PKCS #11 トークンには、証明書、データオブジェクト、公開鍵、秘密鍵、または秘密鍵を含むさまざまなオブジェクトタイプを保存できます。このオブジェクトは、PKCS #11 の URI スキームにより一意に識別できます。

PKCS #11 の URI は、オブジェクト属性に従って、PKCS #11 モジュールで特定のオブジェクトを識別する標準的な方法です。これにより、URI の形式で、すべてのライブラリーとアプリケーションを同じ設定文字列で設定できます。

RHEL では、デフォルトでスマートカード用に OpenSC PKCS #11 ドライバーが提供されています。ただし、ハードウェアトークンと HSM には、システムにカウンターパートを持たない独自の PKCS #11 モジュールがあります。このような PKCS#11 モジュールは、システムに登録されているスマートカードドライバーのラッパーとして機能する p11-kit ツールを使用して登録できます。

システムで独自の PKCS #11 モジュールを有効にするには、新しいテキストファイルを /etc/pkcs11/modules/ ディレクトリーに追加します。

/etc/pkcs11/modules/ ディレクトリーに新しいテキストファイルを作成すると、独自の PKCS #11 モジュールをシステムに追加できます。たとえば、p11-kit の OpenSC 設定ファイルは、以下のようになります。

$ cat /usr/share/p11-kit/modules/opensc.module
module: opensc-pkcs11.so

5.2. スマートカードに保存された SSH 鍵の使用

Red Hat Enterprise Linux では、OpenSSH クライアントでスマートカードに保存されている RSA 鍵および ECDSA 鍵を使用できるようになりました。この手順に従って、パスワードの代わりにスマートカードを使用した認証を有効にします。

前提条件

  • クライアントで、opensc パッケージをインストールして、pcscd サービスを実行している。

手順

  1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵の一覧を表示し、その出力を keys.pub ファイルに保存します。

    $ ssh-keygen -D pkcs11: > keys.pub
    $ ssh-keygen -D pkcs11:
    ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
    ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
  2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pubssh-copy-id コマンドを使用します。

    $ ssh-copy-id -f -i keys.pub username@example.com
  3. 手順 1 の ssh-keygen -D コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。

    $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
    Enter PIN for 'SSH key':
    [example.com] $
  4. ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

    $ cat ~/.ssh/config
    IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
    $ ssh example.com
    Enter PIN for 'SSH key':
    [example.com] $

    OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが PKCS#11 キットに登録されているため、以前のコマンドを簡素化できます。

    $ ssh -i "pkcs11:id=%01" example.com
    Enter PIN for 'SSH key':
    [example.com] $

PKCS #11 の URI の id= の部分を飛ばすと、OpenSSH が、プロキシーモジュールで利用可能な鍵をすべて読み込みます。これにより、必要な入力の量を減らすことができます。

$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $

関連情報

5.3. スマートカードから証明書を使用して認証するアプリケーションの設定

アプリケーションでスマートカードを使用した認証は、セキュリティを強化し、自動化を簡素化する可能性があります。

  • wget ネットワークダウンローダーでは、ローカルに保存された秘密鍵へのパスの代わりに PKCS #11 の URI を指定できるため、安全に保存された秘密鍵と証明書を必要とするタスク用のスクリプトの作成が容易になります。以下に例を示します。

    $ wget --private-key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --certificate 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

    詳細は、wget(1) の man ページを参照してください。

  • curl ツールで使用する PKCS #11 の URI は、以下のように指定します。

    $ curl --key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --cert 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

    詳細は、man ページの curl(1) を参照してください。

    注記

    PINは、スマートカードに保存されているキーへのアクセスを制御するセキュリティ対策であり、設定ファイルにはプレーンテキスト形式のPINが含まれているため、攻撃者がPINを読み取れないように追加の保護を検討してください。たとえば、pin-source 属性を使用して、file: を指定できます。ファイルから PIN を読み込む URI。詳細については、RFC 7512:PKCS #11 URI Scheme Query Attribute Semantics を参照してください。コマンドパスを pin-source 属性の値として使用することには対応していないことに注意してください。

  • Web ブラウザーの Firefox は、p11-kit-proxy モジュールを自動的に読み込みます。つまり、システムで対応しているすべてのスマートカードが自動的に検出されます。TLS クライアント認証を使用した場合、その他に必要な設定はありません。また、サーバーがスマートカードを要求する際に、スマートカードの鍵が自動的に使用されます。

カスタムアプリケーションで PKCS #11 の URI の使用

アプリケーションが GnuTLS ライブラリーまたは NSS ライブラリーを使用する場合、PKCS #11 の URI は PKCS #11 の組み込みサポートで保証されます。また、OpenSSL ライブラリーに依存するアプリケーションは、openssl-pkcs11 エンジンが生成する暗号化ハードウェアモジュールにアクセスできます。

アプリケーションでスマートカードの秘密鍵を使用する必要があり、NSSGnuTLS、および OpenSSL は使用しない場合は、p11-kit を使用して PKCS #11 モジュールの登録を実装します。

関連情報

  • p11-kit(8) の man ページ

5.4. Apache で秘密鍵を保護する HSM の使用

Apache HTTP サーバーは、ハードウェアセキュリティーモジュール (HSM) に保存されている秘密鍵と連携できます。これにより、鍵の漏えいや中間者攻撃を防ぐことができます。通常、これを行うには、ビジーなサーバーに高パフォーマンスの HSM が必要になります。

HTTPS プロトコルの形式でセキュアな通信を行うために、Apache HTTP サーバー (httpd) は OpenSSL ライブラリーを使用します。OpenSSL は、PKCS #11 にネイティブに対応しません。HSM を使用するには、エンジンインターフェースを介して PKCS #11 モジュールへのアクセスを提供する openssl-pkcs11 パッケージをインストールする必要があります。通常のファイル名ではなく PKCS #11 の URI を使用すると、/etc/httpd/conf.d/ssl.conf 設定ファイルでサーバーの鍵と証明書を指定できます。以下に例を示します。

SSLCertificateFile    "pkcs11:id=%01;token=softhsm;type=cert"
SSLCertificateKeyFile "pkcs11:id=%01;token=softhsm;type=private?pin-value=111111"

httpd-manual パッケージをインストールして、TLS 設定を含む Apache HTTP サーバーの完全ドキュメントを取得します。/etc/httpd/conf.d/ssl.conf 設定ファイルで使用可能なディレクティブについては、/usr/share/httpd/manual/mod/mod_ssl.html ファイルで詳しく説明されて ます。

5.5. Nginx で秘密鍵を保護する HSM の使用

Nginx HTTP サーバーは、ハードウェアセキュリティーモジュール (HSM) に保存されている秘密鍵と連携できます。これにより、鍵の漏えいや中間者攻撃を防ぐことができます。通常、これを行うには、ビジーなサーバーに高パフォーマンスの HSM が必要になります。

Nginx は暗号化操作に OpenSSL を使用するため、PKCS #11 への対応は openssl-pkcs11 エンジンを介して行う必要があります。Nginx は現在、HSM からの秘密鍵の読み込みのみに対応します。また、証明書は通常のファイルとして個別に提供する必要があります。/etc/nginx/nginx.conf 設定ファイルの server セクションで ssl_certificate オプションおよび ssl_certificate_key オプションを変更します。

ssl_certificate     /path/to/cert.pem
ssl_certificate_key "engine:pkcs11:pkcs11:token=softhsm;id=%01;type=private?pin-value=111111";

Nginx 設定ファイルの PKCS #11 URI にプレフィックス engine:pkcs11: が必要なことに注意してください。これは、他の pkcs11 プレフィックスがエンジン名を参照するためです。

第6章 polkit を使用したスマートカードへのアクセスの制御

PIN、PIN パッド、バイオメトリクスなどのスマートカードに組み込まれたメカニズムでは防ぐことができない脅威に対処するため、およびより詳細な制御のために、RHEL は polkit フレームワークを使用してスマートカードへのアクセス制御を制御します。

システム管理者は、非特権ユーザーや非ローカルユーザー、サービスに対するスマートカードアクセスなど、特定のシナリオに合わせて polkit を設定できます。

6.1. polkit を介したスマートカードアクセス制御

PC/SC (Personal Computer/Smart Card) プロトコルは、スマートカードとそのリーダーをコンピューティングシステムに統合するための標準を指定します。RHEL では、pcsc-lite パッケージが、PC/SC の API を使用するスマートカードにアクセスするミドルウェアを提供します。このパッケージの一部である pcscd (PC/SC スマートカード) デーモンにより、システムが PC/SC プロトコルを使用してスマートカードにアクセスできるようになります。

PIN、PINパッド、バイオメトリクスなどのスマートカードに組み込まれたアクセス制御メカニズムは、考えられるすべての脅威をカバーするものではないため、RHEL は、より強力なアクセス制御に polkit フレームワークを使用します。polkit 認可マネージャーは、特権操作へのアクセスを許可できます。ディスクへのアクセスを許可することに加えて、polkit を使用して、スマートカードのセキュリティーを保護するポリシーを指定することもできます。たとえば、スマートカードで操作を実行できるユーザーを定義できます。

pcsc-lite パッケージをインストールし、pcscd デーモンを起動すると、システムは、/usr/share/polkit-1/actions/ ディレクトリーで定義されているポリシーを強制します。システム全体のデフォルトのポリシーは、/usr/share/polkit-1/actions/org.debian.pcsc-lite.policy ファイルにあります。Polkit ポリシーファイルは XML 形式を使用し、その構文は man ページの polkit(8) で説明されています。

polkitd は、/etc/polkit-1/rules.d/ ディレクトリーおよび /usr/share/polkit-1/rules.d/ ディレクトリーで、これらのディレクトリーに保存されているルールファイルの変更を監視します。ファイルには、JavaScript 形式の認証ルールが含まれています。システム管理者は、両方のディレクトリーにカスタムルールファイルを追加し、polkitd がファイル名に基づいてアルファベット順に読み込むことができます。2 つのファイルが同じ名前である場合は、最初に /etc/polkit-1/rules.d/ 内のファイルが読み込まれます。

関連情報

  • man ページの polkit(8)polkitd(8)、および pcscd(8)

6.3. PC/SC への polkit 認証の詳細情報の表示

デフォルト設定では、polkit 認証フレームワークは、限られた情報のみをジャーナルログに送信します。新しいルールを追加することで、PC/SC プロトコル関連の polkit ログエントリーを拡張できます。

前提条件

  • システムに pcsc-lite パッケージをインストールしている。
  • pcscd デーモンが実行中である。

手順

  1. /etc/polkit-1/rules.d/ ディレクトリーに新規ファイルを作成します。

    # touch /etc/polkit-1/rules.d/00-test.rules
  2. 選択したエディターでファイルを編集します。以下に例を示します。

    # vi /etc/polkit-1/rules.d/00-test.rules
  3. 以下の行を挿入します。

    polkit.addRule(function(action, subject) {
      if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
      	action.id == "org.debian.pcsc-lite.access_card") {
    	polkit.log("action=" + action);
    	polkit.log("subject=" + subject);
      }
    });

    ファイルを保存して、エディターを終了します。

  4. pcscd サービスおよび polkit サービスを再起動します。

    # systemctl restart pcscd.service pcscd.socket polkit.service

検証

  1. pcscd の認可リクエストを作成します。たとえば、Firefox の Web ブラウザーを開くか、opensc が提供する pkcs11-tool -L を使用します。
  2. 拡張ログエントリーを表示します。以下に例を示します。

    # journalctl -u polkit --since "1 hour ago"
    polkitd[1224]: <no filename>:4: action=[Action id='org.debian.pcsc-lite.access_pcsc']
    polkitd[1224]: <no filename>:5: subject=[Subject pid=2020481 user=user' groups=user,wheel,mock,wireshark seat=null session=null local=true active=true]

関連情報

  • man ページの polkit(8) および polkitd(8)

6.4. 関連情報

第7章 共通システム証明書の使用

共有システム証明書ストレージは、NSS、GnuTLS、OpenSSL、および Java が、システムの証明書アンカーと、拒否リスト情報を取得するデフォルトソースを共有します。トラストストアには、デフォルトで、Mozilla CA の一覧 (信頼される一覧および信頼されない一覧) を含みます。システムは、コア Mozilla CA 一覧を更新したり、証明書一覧を選択したりできます。

7.1. システム全体でトラストストアの使用

Red Hat Enterprise Linux では、統合されたシステム全体のトラストストアが /etc/pki/ca-trust/ ディレクトリーおよび /usr/share/pki/ca-trust-source/ ディレクトリーに置かれています。/usr/share/pki/ca-trust-source/ のトラスト設定は、/etc/pki/ca-trust/ の設定よりも低い優先順位で処理されます。

証明書ファイルは、以下のディレクトリーにインストールされているサブディレクトリーによって扱われ方が異なります。

  • トラストアンカーの場合

    • /usr/share/pki/ca-trust-source/anchors/ または
    • /etc/pki/ca-trust/source/anchors/
  • 信頼されない証明書の場合

    • /usr/share/pki/ca-trust-source/blacklist/ または
    • /etc/pki/ca-trust/source/blacklist/
  • 拡張された BEGIN TRUSTED ファイル形式の証明書の場合

    • /usr/share/pki/ca-trust-source/ または
    • /etc/pki/ca-trust/source/
注記

階層暗号化システムでは、トラストアンカーは一般的に信頼できると想定される、権威のあるエンティティーです。X.509 アーキテクチャーでは、ルート証明書はトラストチェーンの元となるトラストアンカーです。チェーンの検証を有効にするには、信頼元がまずトラストアンカーにアクセスできる必要があります。

7.2. 新しい証明書の追加

新しいソースでシステムのアプリケーションを確認するには、対応する証明書をシステム全体のストアに追加し、update-ca-trust コマンドを使用します。

前提条件

  • ca-certificates パッケージがシステムにインストールされている。

手順

  1. システムで信頼されている CA の一覧に、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/usr/share/pki/ca-trust-source/anchors/ ディレクトリーまたは /etc/pki/ca-trust/source/anchors/ ディレクトリーに証明書ファイルをコピーします。以下に例を示します。

    # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/
  2. システム全体のトラストストア設定を更新するには、update-ca-trust コマンドを実行します。

    # update-ca-trust
注記

Firefox ブラウザーでは update-ca-trust を実行せずに追加した証明書を使用できますが、Red Hat は CA の変更後に update-ca-trust コマンドを使用することを推奨します。Firefox、Epiphany、Chromium などのブラウザーはファイルをキャッシュするので、ブラウザーのキャッシュをクリアするか、ブラウザーを再起動して、現在のシステム証明書の設定を読み込む必要がある場合があります。

7.3. 信頼されているシステム証明書の管理

trust コマンドを使用すると、共有システム全体のトラストストアで証明書を便利な方法で管理できます。

  • トラストアンカーの一覧表示、抽出、追加、削除、または変更を行うには、trust コマンドを使用します。このコマンドの組み込みヘルプを表示するには、引数を付けずに、または --help ディレクティブを付けて実行します。

    $ trust
    usage: trust command <args>...
    
    Common trust commands are:
      list             List trust or certificates
      extract          Extract certificates and trust
      extract-compat   Extract trust compatibility bundles
      anchor           Add, remove, change trust anchors
      dump             Dump trust objects in internal format
    
    See 'trust <command> --help' for more information
  • すべてのシステムのトラストアンカーおよび証明書の一覧を表示するには、trust list コマンドを実行します。

    $ trust list
    pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert
        type: certificate
        label: ACCVRAIZ1
        trust: anchor
        category: authority
    
    pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert
        type: certificate
        label: ACEDICOM Root
        trust: anchor
        category: authority
    ...
  • トラストアンカーをシステム全体のトラストストアに保存するには、trust anchor サブコマンドを使用し、証明書のパスを指定します。path.to/certificate.crt を、証明書およびそのファイル名のパスに置き換えます。

    # trust anchor path.to/certificate.crt
  • 証明書を削除するには、証明書のパス、または証明書の ID を使用します。

    # trust anchor --remove path.to/certificate.crt
    # trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;type=cert"

関連情報

  • trust コマンドのすべてのサブコマンドは、以下のような詳細な組み込みヘルプを提供します。

    $ trust list --help
    usage: trust list --filter=<what>
    
      --filter=<what>     filter of what to export
                            ca-anchors        certificate anchors
    ...
      --purpose=<usage>   limit to certificates usable for the purpose
                            server-auth       for authenticating servers
    ...

7.4. 関連情報

  • update-ca-trust(8) および trust(1) の man ページ

第8章 設定コンプライアンスおよび脆弱性スキャンの開始

コンプライアンス監査は、指定したオブジェクトが、コンプライアンスポリシーに指定されているすべてのルールに従っているかどうかを判断するプロセスです。コンプライアンスポリシーは、コンピューティング環境で使用される必要な設定を指定するセキュリティー専門家が定義します。これは多くの場合は、チェックリストの形式を取ります。

コンプライアンスポリシーは組織により大幅に異なることがあり、同一組織内でもシステムが異なるとポリシーが異なる可能性があります。ポリシーは、各システムの目的や、組織におけるシステム重要性により異なります。カスタマイズしたソフトウェア設定や導入の特徴によっても、カスタマイズしたポリシーのチェックリストが必要になってきます。

8.1. RHEL における設定コンプライアンスツール

Red Hat Enterprise Linux は、コンプライアンス監査を完全に自動化できるツールを提供します。このツールは SCAP (Security Content Automation Protocol) 規格に基づいており、コンプライアンスポリシーの自動化に合わせるように設計されています。

  • SCAP Workbench - scap-workbench グラフィカルユーティリティーは、1 台のローカルシステムまたはリモートシステムで構成スキャンと脆弱性スキャンを実行するように設計されています。これらのスキャンと評価に基づくセキュリティーレポートの生成にも使用できます。
  • OpenSCAP: OpenSCAP ライブラリーは、付随する oscap コマンドラインユーティリティーとともに、ローカルシステムで構成スキャンと脆弱性スキャンを実行するように設計されています。これにより、設定コンプライアンスのコンテンツを検証し、スキャンおよび評価に基づいてレポートおよびガイドを生成します。
  • SCAP Security Guide (SSG) - scap-security-guide パッケージは、Linux システム向けの最新のセキュリティーポリシーコレクションを提供します。このガイダンスは、セキュリティー強化に関する実践的なアドバイスのカタログから構成されます (該当する場合は、法規制要件へのリンクが含まれます)。このプロジェクトは、一般的なポリシー要件と特定の実装ガイドラインとの間にあるギャップを埋めることを目的としています。
  • Script Check Engine (SCE) - SCE は SCAP プロトコルの拡張機能であり、この機能を使用すると管理者が Bash、Python、Ruby などのスクリプト言語を使用してセキュリティーコンテンツを記述できるようになります。SCE 拡張機能は、openscap-engine-sce パッケージで提供されます。SCE 自体は SCAP 標準規格の一部ではありません。

複数のリモートシステムで自動コンプライアンス監査を実行する必要がある場合は、Red Hat Satellite 用の OpenSCAP ソリューションを利用できます。

8.2. 脆弱性スキャン

8.2.1. Red Hat Security Advisories OVAL フィード

Red Hat Enterprise Linux のセキュリティー監査機能は、SCAP(Security Content Automation Protocol)標準に基づいています。SCAP は、自動化された設定、脆弱性およびパッチの確認、技術的な制御コンプライアンスアクティビティー、およびセキュリティーの測定に対応している多目的な仕様のフレームワークです。

SCAP 仕様は、スキャナーまたはポリシーエディターの実装が義務付けられていなくても、セキュリティーコンテンツの形式がよく知られて標準化されているエコシステムを作成します。これにより、組織は、採用しているセキュリティーベンダーの数に関係なく、セキュリティポリシー (SCAP コンテンツ) を構築するのは一度で済みます。

セキュリティー検査言語 OVAL (Open Vulnerability Assessment Language) は、SCAP に不可欠で最も古いコンポーネントです。その他のツールやカスタマイズされたスクリプトとは異なり、OVAL は、宣言型でリソースが必要な状態を記述します。OVAL コードは、スキャナーと呼ばれる OVAL インタープリターツールを使用して直接実行されることは決してありません。OVAL が宣言型であるため、評価されるシステムの状態が偶然修正されることはありません。

他のすべての SCAP コンポーネントと同様に、OVAL は XML に基づいています。SCAP 標準規格は、いくつかのドキュメント形式を定義します。この形式にはそれぞれ異なる種類の情報が記載され、異なる目的に使用されます。

Red Hat 製品セキュリティー を使用すると、Red Hat 製品をお使いのお客様に影響を及ぼすセキュリティー問題をすべて追跡して調査します。Red Hat カスタマーポータルで簡潔なパッチやセキュリティーアドバイザリーを適時提供します。Red Hat は OVAL パッチ定義を作成してサポートし、マシンが判読可能なセキュリティーアドバイザリーを提供します。

プラットフォーム、バージョン、およびその他の要因が異なるため、Red Hat 製品セキュリティー質的な脆弱性の重大度評価は、サードパーティーが提供する Common Vulnerability Scoring System (CHC) のベースライン評価と完全に一致しているわけではありません。したがって、サードパーティーが提供する定義ではなく、RHSA OVAL 定義を使用することが推奨されます。

RHSA OVAL 定義 は完全なパッケージとして利用でき、新しいセキュリティーアドバイザリーが Red Hat カスタマーポータルで利用可能になってから 1 時間以内に更新されます。

各 OVAL パッチ定義は、Red Hat セキュリティーアドバイザリー (RHSA) と 1 対 1 にマッピングしています。RHSA には複数の脆弱性に対する修正が含まれるため、各脆弱性は、共通脆弱性識別子 (Common Vulnerabilities and Exposures (CVE)) 名ごとに表示され、公開バグデータベースの該当箇所へのリンクが示されます。

RHSA OVAL 定義は、システムにインストールされている RPM パッケージで脆弱なバージョンを確認するように設計されています。この定義は拡張でき、パッケージが脆弱な設定で使用されているかどうかを見つけるなど、さらに確認できるようにすることができます。この定義は、Red Hat が提供するソフトウェアおよび更新に対応するように設計されています。サードパーティーソフトウェアのパッチ状態を検出するには、追加の定義が必要です。

注記

Red Hat Enterprise Linux Compliance サービス向けの Red Hat Insights は、IT セキュリティーおよびコンプライアンス管理者が Red Hat Enterprise Linux システムのセキュリティーポリシーコンプライアンスの評価、監視、および報告に役立ちます。Compliance サービス UI 内で SCAP セキュリティーポリシーを作成して、管理することもできます。

8.2.2. システムの脆弱性のスキャン

oscap コマンドラインユーティリティーを使用すると、ローカルシステムのスキャン、設定コンプライアンスコンテンツの確認、ならびにスキャンおよび評価を基にしたレポートとガイドの生成が可能です。このユーティリティーは、OpenSCAP ライブラリーのフロントエンドとしてサービスを提供し、その機能を処理する SCAP コンテンツのタイプに基づいてモジュール (サブコマンド) にグループ化します。

前提条件

  • openscap-scanner パッケージおよび bzip2 パッケージがインストールされている。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml
  2. システムの脆弱性をスキャンし、vulnerability.html ファイルに結果を保存します。

    # oscap oval eval --report vulnerability.html rhel-9.oval.xml

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox vulnerability.html &

関連情報

8.2.3. リモートシステムの脆弱性のスキャン

SSH プロトコルで oscap-ssh ツールを使用して、OpenSCAP スキャナーでリモートシステムの脆弱性を確認することもできます。

前提条件

  • スキャンに使用するシステムに openscap-utils パッケージおよび bzip2 パッケージがインストールされている。
  • リモートシステムに openscap-scanner パッケージがインストールされている。
  • リモートシステムで SSH サーバーが実行している。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml
  2. 脆弱性に対して、ホスト名 machine1、ポート 22 で実行する SSH、およびユーザー名 joesec でリモートシステムをスキャンし、結果を remote-vulnerability.html ファイルに保存します。

    # oscap-ssh joesec@machine1 22 oval eval --report remote-vulnerability.html rhel-9.oval.xml

関連情報

8.3. 設定コンプライアンススキャン

8.3.1. RHEL の設定コンプライアンス

設定コンプライアンススキャンを使用して、特定の組織で定義されているベースラインに準拠できます。たとえば、米国政府と協力している場合は、システムをOperating System Protection Profile (OSPP) に準拠させ、支払い処理業者の場合は、システムを Payment Card Industry Data Security Standard (PCI-DSS) に準拠させなければならない場合があります。設定コンプライアンススキャンを実行して、システムセキュリティーを強化することもできます。

Red Hat は、影響を受けるコンポーネントに対する Red Hat のベストプラクティスに従っているため、SCAP Security Guide パッケージで提供される Security Content Automation Protocol (SCAP) コンテンツに従うことを推奨します。

SCAP Security Guide パッケージは、SCAP 1.2 および SCAP 1.3 標準規格に準拠するコンテンツを提供します。openscap scanner ユーティリティーは、SCAP Security Guide パッケージで提供される SCAP 1.2 および SCAP 1.3 コンテンツの両方と互換性があります。

重要

設定コンプライアンススキャンを実行しても、システムが準拠していることは保証されません。

SCAP セキュリティーガイドスイートは、データストリームのドキュメント形式で、複数のプラットフォームのプロファイルを提供します。データストリームは、定義、ベンチマーク、プロファイル、および個々のルールが含まれるファイルです。各ルールでは、コンプライアンスの適用性と要件を指定します。RHEL は、セキュリティーポリシーを扱う複数のプロファイルを提供します。Red Hat データストリームには、業界標準の他に、失敗したルールの修正に関する情報も含まれます。

コンプライアンススキャンリソースの構造

Data stream
   ├── xccdf
   |      ├── benchmark
   |            ├── profile
   |            |    ├──rule reference
   |            |    └──variable
   |            ├── rule
   |                 ├── human readable data
   |                 ├── oval reference
   ├── oval          ├── ocil reference
   ├── ocil          ├── cpe reference
   └── cpe           └── remediation

プロファイルは、OSPP、PCI-DSS、Health Insurance Portability and Accountability Act (HIPAA) などのセキュリティーポリシーに基づく一連のルールです。これにより、セキュリティー標準規格に準拠するために、システムを自動で監査できます。

プロファイルを変更 (調整) して、パスワードの長さなどの特定のルールをカスタマイズできます。プロファイルの調整の詳細は、「SCAP Workbench を使用したセキュリティープロファイルのカスタマイズ」を参照してください。

8.3.2. OpenSCAP スキャン結果の例

システムのさまざまなプロパティーと、OpenSCAP スキャンに適用されるデータストリームおよびプロファイルによっては、各ルールによって特定の結果が生成されることがあります。考えられる結果のリストで、その意味を簡単に説明します。

表8.1 OpenSCAP スキャン結果の例

結果説明

Pass

このスキャンでは、このルールとの競合が見つかりませんでした。

Fail

スキャンにより、このルールとの競合が検出されました。

Not checked

OpenSCAP はこのルールの自動評価を実行しません。システムがこのルールに手動で準拠しているかどうかを確認してください。

該当なし

このルールは、現在の設定には適用されません。

Not selected

このルールはプロファイルには含まれません。OpenSCAP はこのルールを評価せず、結果にこのようなルールを表示しません。

Error

スキャンでエラーが発生しました。詳細は、--verbose DEVEL オプションを指定して oscap コマンドで確認できます。バグレポート を作成することを検討してください。

Unknown

スキャンで予期しない状況が発生しました。詳細は、`--verbose DEVEL オプションを指定して oscap コマンドを入力できます。バグレポート を作成することを検討してください。

8.3.3. 設定コンプライアンスのプロファイルの表示

スキャンまたは修復にプロファイルを使用することを決定する前に、その一覧を表示して oscap info サブコマンドで詳しい説明を確認できます。

前提条件

  • openscap-scanner パッケージおよび scap-security-guide パッケージがインストールされている。

手順

  1. SCAP Security Guide プロジェクトが提供するセキュリティーコンプライアンスプロファイルで利用可能なファイルをすべて表示します。

    $ ls /usr/share/xml/scap/ssg/content/
    ssg-rhel9-ds.xml
  2. oscap info サブコマンドを使用して、選択したデータストリームに関する詳細情報を表示します。データストリームを含む XML ファイルは、名前に -ds 文字列で示されます。Profiles セクションでは、利用可能なプロファイルと、その ID の一覧を確認できます。

    $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
    Profiles:
    ...
      Title: Australian Cyber Security Centre (ACSC) Essential Eight
        Id: xccdf_org.ssgproject.content_profile_e8
      Title: Health Insurance Portability and Accountability Act (HIPAA)
        Id: xccdf_org.ssgproject.content_profile_hipaa
      Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 9
        Id: xccdf_org.ssgproject.content_profile_pci-dss
    ...
  3. データストリームファイルからプロファイルを選択し、選択したプロファイルに関する追加情報を表示します。そのためには、oscap info--profile オプションを指定した後に、直前のコマンドの出力で表示された ID の最後のセクションを指定します。たとえば、HIPPA プロファイルの ID は xccdf_org.ssgproject.content_profile_hipaa で、--profile オプションの値は hipaa です。

    $ oscap info --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
    ...
    Profile
    	Title: [RHEL9 DRAFT] Health Insurance Portability and Accountability Act (HIPAA)
    	Id: xccdf_org.ssgproject.content_profile_hipaa
    
    	Description: The HIPAA Security Rule establishes U.S. national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity. The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and security of electronic protected health information.  This profile configures Red Hat Enterprise Linux 9 to the HIPAA Security Rule identified for securing of electronic protected health information. Use of this profile in no way guarantees or makes claims against legal compliance against the HIPAA Security Rule(s).

関連情報

  • scap-security-guide (8) の man ページ

8.3.4. 特定のベースラインによる設定コンプライアンスの評価

システムが特定のベースラインに準拠しているかどうかを確認するには、次の手順に従います。

前提条件

  • openscap-scanner パッケージおよび scap-security-guide パッケージがインストールされている。
  • システムが準拠する必要があるベースライン内のプロファイルの ID を知っている必要があります。ID を見つけるには、「設定コンプライアンスのプロファイルの表示」を参照してください。

手順

  1. 選択したプロファイルでそのシステムがどのように複雑であるかを評価し、スキャン内容を保存すると、以下のように HTML ファイル (report.html) に結果が表示されます。

    $ sudo oscap xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
  2. オプション:コンプライアンスに対して、ホスト名 machine1、ポート 22 で実行する SSH、およびユーザー名 joesec でリモートシステムをスキャンし、結果を remote-report.html ファイルに保存します。

    $ oscap-ssh joesec@machine1 22 xccdf eval --report remote_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

関連情報

  • scap-security-guide (8) の man ページ
  • /usr/share/doc/scap-security-guide/ ディレクトリーの SCAP セキュリティーガイドに関するドキュメント
  • /usr/share/doc/scap-security-guide/guides/ssg-rhel9-guide-index.html - [Guide to the Secure Configuration of Red Hat Enterprise Linux 9] installed with the scap-security-guide-doc package

8.4. 特定のベースラインに合わせたシステムの修復

この手順を使用して、特定のベースラインに合わせて RHEL システムを修正します。この例では、Health Insurance Portability and Accountability Act (HIPAA) プロファイルを使用します。

警告

修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修正は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

前提条件

  • RHEL システムに、scap-security-guide パッケージがインストールされている。

手順

  1. oscap コマンドに --remediate オプションを指定して使用します。

    $ sudo oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
  2. システムを再起動します。

検証

  1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

    $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

関連情報

  • scap-security-guide(8) および oscap(8) の man ページ

8.5. SSG Ansible Playbook を使用して特定のベースラインに合わせたシステムの修復

以下の手順に従って、SCAP Security Guide プロジェクトの Ansible Playbook ファイルを使用して、特定のベースラインでシステムを修正します。この例では、Health Insurance Portability and Accountability Act (HIPAA) プロファイルを使用します。

警告

修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修正は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

前提条件

  • scap-security-guide パッケージがインストールされている。
  • ansible-core パッケージがインストールされている。詳細は、Ansible インストールガイドを参照してください。
注記

RHEL 8.6 以降のバージョンでは、Ansible Engine は ansible-core パッケージに置き換えられました。これには、組み込みモジュールのみが含まれます。Ansible 修復の多くは、community コレクションおよび Portable Operating System Interface (POSIX) コレクションのモジュールを使用することに注意してください。これは組み込みモジュールには含まれていません。この場合は、Ansible 修復の代わりに Bash 修復を使用できます。RHEL 9 の Red Hat Connector には、修復 Playbook を Ansible Core で機能させるのに必要な Ansible モジュールが含まれています。

手順

  1. Ansible を使用して OSPP に合わせてシステムを修正します。

    # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-hipaa.yml
  2. システムを再起動します。

検証

  1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

    # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

関連情報

8.6. システムを特定のベースラインに合わせるための修復用 Ansible Playbook の作成

以下の手順に従って、必要な修復のみを含む Ansible Playbook を作成し、システムを特定のベースラインに合わせます。この例では、Health Insurance Portability and Accountability Act (HIPAA) プロファイルを使用します。この手順では、要件を満たしていない小規模の Playbook を作成します。以下の手順に従うと、システムを変更せずに、後のアプリケーション用にファイルの準備を行うだけです。

注記

RHEL 9 では、Ansible Engine は、組み込みモジュールのみを含む ansible-core パッケージに置き換えられました。Ansible 修復の多くは、community コレクションおよび Portable Operating System Interface (POSIX) コレクションのモジュールを使用することに注意してください。これは組み込みモジュールには含まれていません。この場合は、Bash 修復を Ansible 修復の代わりに使用できます。RHEL 9.0 の Red Hat Connector には、修復 Playbook を Ansible Core で機能させるのに必要な Ansible モジュールが含まれています。

前提条件

  • scap-security-guide パッケージがインストールされている。

手順

  1. システムをスキャンして結果を保存します。

    # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
  2. 前の手順で生成されたファイルに基づいて Ansible Playbook を生成します。

    # oscap xccdf generate fix --fix-type ansible --profile hipaa --output hipaa-remediations.yml hipaa-results.xml
  3. hippa-remediations.yml ファイルには、手順 1 で実行されたスキャン中に失敗したルールの Ansible 修復が含まれています。この生成されたファイルを確認した後、ansible-playbook hipaa-remediations.yml コマンドで適用できます。

検証

  • お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが hipaa-remediations.yml ファイルに含まれていることを確認します。

関連情報

8.7. 後でアプリケーションを修復するための Bash スクリプトの作成

この手順を使用して、システムを HIPAA などのセキュリティープロファイルと調整する修正を含む Bash スクリプトを作成します。次の手順では、システムに変更を加えることなく、後のアプリケーション用にファイルを準備する方法を説明します。

前提条件

  • RHEL システムに、scap-security-guide パッケージがインストールされている。

手順

  1. oscap コマンドを使用してシステムをスキャンし、結果を XML ファイルに保存します。以下の例では、oscaphipaa プロファイルに対してシステムを評価します。

    # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
  2. 前の手順で生成された結果ファイルに基づいて Bash スクリプトを生成します。

    # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml
  3. hippa-dss-remediations.sh ファイルには、手順 1 で実行されたスキャン中に失敗したルールの修復が含まれます。この生成されたファイルを確認したら、このファイルと同じディレクトリー内で ./hipaa-remediations.sh コマンドを使用して適用できます。

検証

  • お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが hipaa-remediations.sh ファイルに含まれていることを確認します。

関連情報

  • scap-security-guide(8)oscap(8)、および bash(1) の man ページ

8.8. SCAP Workbench を使用したカスタムプロファイルでシステムのスキャン

SCAP Workbench (scap-workbench) パッケージはグラフィカルユーティリティーで、1 台のローカルシステムまたはリモートシステムで構成スキャンと脆弱性スキャンを実行し、システムの修復を実行して、スキャン評価に基づくレポートを生成します。oscap コマンドラインユーティリティーとの比較は、SCAP Workbench には限定的な機能しかないことに注意してください。SCAP Workbench は、データストリームファイルの形式でセキュリティーコンテンツを処理します。

8.8.1. SCAP Workbench を使用したシステムのスキャンおよび修復

選択したセキュリティーポリシーに対してシステムを評価するには、以下の手順に従います。

前提条件

  • scap-workbench パッケージがシステムにインストールされている。

手順

  1. GNOME Classic デスクトップ環境から SCAP Workbench を実行するには、Super キーを押して アクティビティーの概要 を開き、scap-workbenchと入力して Enterを押します。または、次のコマンドを実行します。

    $ scap-workbench &
  2. 以下のオプションのいずれかを使用してセキュリティーポリシーを選択します。

    • 開始ウィンドウの Load Content ボタン
    • Open content from SCAP Security Guide
    • File メニューの Open Other Content で、XCCDF、SCAP RPM、またはデータストリームファイルの各ファイルを検索します。

      SCAP workbench の起動
  3. Remediate チェックボックスを選択して、システム設定の自動修正を行うことができます。このオプションを有効にすると、SCAP Workbench は、ポリシーにより適用されるセキュリティールールに従ってシステム設定の変更を試みます。このプロセスは、システムスキャン時に失敗した関連チェックを修正する必要があります。

    警告

    修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修正は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

  4. Scan ボタンをクリックし、選択したプロファイルでシステムをスキャンします。

    SCAP ワークベンチの結果
  5. スキャン結果を XCCDF ファイル、ARF ファイル、または HTML ファイルの形式で保存するには、Save Results コンボボックスをクリックします。HTML Report オプションを選択して、スキャンレポートを、人間が判読できる形式で生成します。XCCDF 形式および ARF (データストリーム) 形式は、追加の自動処理に適しています。3 つのオプションはすべて繰り返し選択できます。
  6. 結果ベースの修復をファイルにエクスポートするには、ポップアップメニューの Generate remediation role を使用します。

8.8.2. SCAP Workbench を使用したセキュリティープロファイルのカスタマイズ

セキュリティープロファイルをカスタマイズするには、特定のルール (パスワードの最小長など) のパラメーターを変更し、別の方法で対象とするルールを削除し、追加のルールを選択して内部ポリシーを実装できます。プロファイルをカスタマイズして新しいルールを定義することはできません。

以下の手順は、プロファイルをカスタマイズ (調整) するための SCAP Workbench の使用を示しています。oscap コマンドラインユーティリティーで使用するようにカスタマイズしたプロファイルを保存することもできます。

前提条件

  • scap-workbench パッケージがシステムにインストールされている。

手順

  1. SCAP Workbench を実行し、Open content from SCAP Security Guide または File メニューの Open Other Content を使用してカスタマイズするプロファイルを選択します。
  2. 選択したセキュリティープロファイルを必要に応じて調整するには、Customize ボタンをクリックします。

    これにより、元のデータストリームファイルを変更せずに現在選択されているプロファイルを変更できる新しいカスタマイズウィンドウが開きます。新しいプロファイル ID を選択します。

    新しいプロファイルの ID の選択
  3. 論理グループに分けられたルールを持つツリー構造を使用するか、Search フィールドを使用して変更するルールを検索します。
  4. ツリー構造のチェックボックスを使用した include ルールまたは exclude ルール、または必要に応じてルールの値を変更します。

    OSPP プロファイルにおけるルールのカスタマイズ
  5. OK ボタンをクリックして変更を確認します。
  6. 変更内容を永続的に保存するには、以下のいずれかのオプションを使用します。

    • File メニューの Save Customization Only を使用して、カスタマイズファイルを別途保存します。
    • File メニュー Save All を選択して、すべてのセキュリティーコンテンツを一度に保存します。

      Into a directory オプションを選択すると、SCAP Workbench は、データストリームファイルおよびカスタマイズファイルの両方を、指定した場所に保存します。これはバックアップソリューションとして使用できます。

      As RPM オプションを選択すると、SCAP Workbench に、データストリームファイル、ならびにカスタマイズファイルを含む RPM パッケージの作成を指示できます。これは、リモートでスキャンできないシステムにセキュリティーコンテンツを配布したり、詳細な処理のためにコンテンツを配信するのに便利です。

注記

SCAP Workbench は、カスタマイズしたプロファイル向けの結果ベースの修正に対応していないため、oscap コマンドラインユーティリティーでエクスポートした修正を使用します。

8.9. インストール直後にセキュリティープロファイルに準拠するシステムのデプロイメント

OpenSCAP スイートを使用して、インストールプロセスの直後に、OSPP や PCI-DSS、HIPAA プロファイルなどのセキュリティープロファイルに準拠する RHEL システムをデプロイできます。このデプロイメント方法を使用すると、修正スクリプトを使用して後で適用できない特定のルール (パスワードの強度とパーティション化のルールなど) を適用できます。

8.9.1. GUIを備えたサーバーと互換性のないプロファイル

SCAP セキュリティーガイド の一部として提供される一部のセキュリティープロファイルは、Server with GUI ベースの環境の拡張パッケージセットと互換性がない場合があります。したがって、次のプロファイルのいずれかに準拠するシステムをインストールする場合は、Server with GUIを選択しないでください。

表8.2 GUIを備えたサーバーと互換性のないプロファイル

プロファイル名プロファイル ID理由備考

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 2 - Server

xccdf_org.ssgproject.content_profile_cis

パッケージxorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utils、およびxorg-x11-server-Xwaylandは、Server with GUIパッケージセットの一部ですが、ポリシーではそれらを削除する必要があります。

 

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server

xccdf_org.ssgproject.content_profile_cis_server_l1

パッケージxorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utils、およびxorg-x11-server-Xwaylandは、Server with GUIパッケージセットの一部ですが、ポリシーではそれらを削除する必要があります。

 

Unclassified Information in Non-federal Information Systems and Organizations (NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

nfs-utilsパッケージはServer with GUIパッケージセットの一部ですが、ポリシーではその削除が必要です。

 

[RHEL9ドラフト] Protection Profile for General Purpose Operating Systems

xccdf_org.ssgproject.content_profile_ospp

nfs-utilsパッケージはServer with GUIパッケージセットの一部ですが、ポリシーではその削除が必要です。

BZ#1787156

[ドラフト] DISA STIG for Red Hat Enterprise Linux 9

xccdf_org.ssgproject.content_profile_stig

パッケージxorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utils、およびxorg-x11-server-Xwaylandは、Server with GUIパッケージセットの一部ですが、ポリシーではそれらを削除する必要があります。

RHELシステムをDISA STIGに準拠したServer with GUI としてインストールするには、DISA STIG with GUI プロファイルを使用できます(BZ#1648162)

8.9.2. グラフィカルインストールを使用したベースライン準拠の RHEL システムのデプロイメント

この手順を使用して、特定のベースラインに合わせた RHEL システムをデプロイします。この例では、OSPP (Protection Profile for General Purpose Operating System) を使用します。

警告

SCAP セキュリティーガイド の一部として提供される一部のセキュリティープロファイルは、Server with GUI ベースの環境の拡張パッケージセットと互換性がない場合があります。詳細については、 GUIサーバーと互換性のないプロファイルを参照してください。

前提条件

  • グラフィカル インストールプログラムでシステムを起動している。OSCAP Anaconda アドオン はインタラクティブなテキストのみのインストールをサポートしていないことに注意してください。
  • インストール概要 画面を開いている。

手順

  1. インストール概要 画面で、ソフトウェアの選択 をクリックします。ソフトウェアの選択 画面が開きます。
  2. ベース環境 ペインで、サーバー 環境を選択します。ベース環境は、1 つだけ選択できます。
  3. 完了 をクリックして設定を適用し、インストール概要 画面に戻ります。
  4. セキュリティーポリシー をクリックします。セキュリティーポリシー 画面が開きます。
  5. システムでセキュリティーポリシーを有効にするには、セキュリティーポリシーの適用ON に切り替えます。
  6. プロファイルペインで Protection Profile for General Purpose Operating Systems プロファイルを選択します。
  7. プロファイルの選択 をクリックして選択を確定します。
  8. 画面下部に表示される Protection Profile for General Purpose Operating Systems の変更を確定します。残りの手動変更を完了します。
  9. OSPP には、準拠する必要がある厳密なパーティション分割要件があるため、/boot/home/var/var/log/var/tmp、および /var/log/audit にそれぞれパーティションを作成します。
  10. グラフィカルインストールプロセスを完了します。

    注記

    グラフィカルインストールプログラムは、インストールに成功すると、対応するキックスタートファイルを自動的に作成します。/root/anaconda-ks.cfg ファイルを使用して、OSPP 準拠のシステムを自動的にインストールできます。

検証

  • インストール完了後にシステムの現在のステータスを確認するには、システムを再起動して新しいスキャンを開始します。

    # oscap xccdf eval --profile ospp --report eval_postinstall_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

8.9.3. キックスタートを使用したベースライン準拠の RHEL システムのデプロイメント

この手順を使用して、特定のベースラインに合わせた RHEL システムをデプロイします。この例では、OSPP (Protection Profile for General Purpose Operating System) を使用します。

前提条件

  • RHEL 9 システムに、scap-security-guide パッケージがインストールされている。

手順

  1. キックスタートファイル /usr/share/scap-security-guide/kickstart/ssg-rhel9-ospp-ks.cfg を、選択したエディターで開きます。
  2. 設定要件を満たすように、パーティション設定スキームを更新します。OSPP コンプライアンスでは、/boot/home/var/var/log/var/tmp、および /var/log/audit にそれぞれ設定したパーティションを維持して、パーティションのサイズのみを変更できます。
  3. キックスタートインストールを開始する方法は、「キックスタートインストールの開始」を参照してください。
重要

キックスタートファイルのパスワードでは、OSPP の要件が確認されていません。

検証

  1. インストール完了後にシステムの現在のステータスを確認するには、システムを再起動して新しいスキャンを開始します。

    # oscap xccdf eval --profile ospp --report eval_postinstall_report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

関連情報

8.10. コンテナーおよびコンテナーイメージの脆弱性スキャン

以下の手順を使用して、コンテナーまたはコンテナーイメージのセキュリティー脆弱性を検索します。

前提条件

  • openscap-utils パッケージおよび bzip2 パッケージがインストールされている。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2 | bzip2 --decompress > rhel-9.oval.xml
  2. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

    # podman images
    REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB
  3. コンテナーまたはコンテナーイメージで脆弱性をスキャンし、結果を vulnerability.html ファイルに保存します。

    # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-9.oval.xml

    oscap-podman コマンドには root 権限が必要で、コンテナーの ID は最初の引数であることに注意してください。

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox vulnerability.html &

関連情報

  • 詳細は、oscap-podman(8) および oscap(8) の man ページを参照してください。

8.11. 特定のベースラインを使用したコンテナーまたはコンテナーイメージのセキュリティーコンプライアンスの評価

以下の手順に従い、OSPP (Operating System Protection Profile) や PCI-DSS (Payment Card Industry Data Security Standard)、Health Insurance Portability and Accountability Act (HIPAA) などの特定のセキュリティーベースラインのあるコンテナーまたはコンテナーイメージのコンプライアンスを評価します。

前提条件

  • openscap-utils パッケージおよび scap-security-guide パッケージがインストールされている。

手順

  1. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

    # podman images
    REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi9/ubi   latest   096cae65a207   7 weeks ago   239 MB
  2. HIPAA プロファイルでコンテナーイメージのコンプライアンスを評価し、スキャン結果を report.html ファイルに保存します。

    # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

    OSPP または PCI-DSS ベースラインでセキュリティーコンプライアンスを評価する場合は、096cae65a207 をコンテナーイメージの ID に、hipaa の値を ospp または pci-dss に置き換えます。oscap-podman コマンドには、root 権限が必要なことに注意してください。

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox report.html &
注記

notapplicable が付いているルールは、コンテナー化されたシステムには適用されないルールです。これらのルールは、ベアメタルおよび仮想化システムにのみ適用されます。

関連情報

  • oscap-podman(8) および scap-security-guide(8)のmanページ。
  • /usr/share/doc/scap-security-guide/ ディレクトリー

8.12. RHEL 9 で対応する SCAP セキュリティーガイドプロファイル

RHEL の特定のマイナーリリースで提供される SCAP コンテンツのみを使用します。これは、ハードニングに参加するコンポーネントが新機能で更新されるためです。SCAP コンテンツは、この更新を反映するように変更されますが、常に後方互換性があるわけではありません。

以下の表では、RHEL 9 で提供されるプロファイルと、プロファイルが適合するポリシーのバージョンを紹介しています。

表8.3 RHEL 9.0 で対応している SCAP セキュリティーガイドプロファイル

プロファイル名プロファイル IDポリシーバージョン

Security of Information Systems (ANSSI) BP-028 Enhanced Level

xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced

1.2

French National Agency for the Security of Information Systems (ANSSI) BP-028 High Level

xccdf_org.ssgproject.content_profile_anssi_bp28_high

1.2

French National Agency for the Security of Information Systems (ANSSI) BP-028 Intermediary Level

xccdf_org.ssgproject.content_profile_anssi_bp28_intermediary

1.2

French National Agency for the Security of Information Systems (ANSSI) BP-028 Minimal Level

xccdf_org.ssgproject.content_profile_anssi_bp28_minimal

1.2

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 2 - Server

xccdf_org.ssgproject.content_profile_cis

ドラフト[a]

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server

xccdf_org.ssgproject.content_profile_cis_server_l1

ドラフト[a]

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Workstation

xccdf_org.ssgproject.content_profile_cis_workstation_l1

ドラフト[a]

[ドラフト] CIS Red Hat Enterprise Linux 9 Benchmark for Level 2 - Workstation

xccdf_org.ssgproject.content_profile_cis_workstation_l2

ドラフト[a]

[DRAFT] Unclassified Information in Non-federal Information Systems and Organizations(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

r2

Australian Cyber Security Centre (ACSC) Essential Eight

xccdf_org.ssgproject.content_profile_e8

バージョン付けされていません

Health Insurance Portability and Accountability Act (HIPAA)

xccdf_org.ssgproject.content_profile_hipaa

バージョン付けされていません

Australian Cyber Security Centre (ACSC) ISM Official

xccdf_org.ssgproject.content_profile_ism_o

バージョン付けされていません

[DRAFT] Protection Profile for General Purpose Operating Systems

xccdf_org.ssgproject.content_profile_ospp

4.2.1

PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 9

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[ドラフト] DISA STIG for Red Hat Enterprise Linux 9

xccdf_org.ssgproject.content_profile_stig

ドラフト[b]

[ドラフト] DISA STIG with GUI for Red Hat Enterprise Linux 9

xccdf_org.ssgproject.content_profile_stig_gui

ドラフト[b]

[a] CIS は RHEL 9 の公式ベンチマークを公開していません。
[b] DISA は RHEL 9 の公式ベンチマークを公開していません。

第9章 AIDE で整合性の確認

AIDE (Advanced Intrusion Detection Environment) は、システムのファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確保し、システムの侵入を検出します。

9.1. AIDE のインストール

以下の手順は、AIDE をインストールして、そのデータベースを開始するのに必要です。

前提条件

  • AppStream リポジトリーが有効になっている。

手順

  1. aide パッケージをインストールするには、次のコマンドを実行します。

    # dnf install aide
  2. 初期データベースを生成するには、次のコマンドを実行します。

    # aide --init
    注記

    デフォルト設定では、aide --init コマンドは、/etc/aide.conf ファイルで定義するディレクトリーとファイルのセットのみを確認します。ディレクトリーまたはファイルを AIDE データベースに追加し、監視パラメーターを変更するには、/etc/aide.conf を変更します。

  3. データベースの使用を開始するには、初期データベースのファイル名から末尾の .new を削除します。

    # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  4. AIDE データベースの場所を変更するには、/etc/aide.conf ファイルを編集して、DBDIR 値を変更します。追加のセキュリティーのデータベース、設定、/usr/sbin/aide バイナリーファイルを、読み取り専用メディアなどの安全な場所に保存します。

9.2. AIDE を使用した整合性チェックの実行

前提条件

  • AIDE が適切にインストールされ、そのデータベースが初期化されている。「AIDE のインストール」を参照してください。

手順

  1. 手動でチェックを開始するには、以下を行います。

    # aide --check
    Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
    AIDE found differences between database and filesystem!!
    ...
    [trimmed for clarity]
  2. 最低でも、AIDE は週ごとに実行するようにシステムを設定します。最適な設定としては、AIDE を毎日実行します。たとえば、AIDE を毎日午前 04:05 に実行するようにスケジュールするには、cron コマンドを使用して、次の行を /etc/crontab ファイルを追加します。

     05 4 * * * root /usr/sbin/aide --check

9.3. AIDE データベースの更新

Red Hat は、システムの変更 (パッケージの更新、設定ファイルの修正など) を確認してから、基本となる AIDE データベースを更新することを推奨します。

前提条件

  • AIDE が適切にインストールされ、そのデータベースが初期化されている。「AIDE のインストール」を参照してください。

手順

  1. 基本となる AIDE データベースを更新します。

    # aide --update

    aide --update コマンドは、/var/lib/aide/aide.db.new.gz データベースファイルを作成します。

  2. 整合性チェックで更新したデータベースを使用するには、ファイル名から末尾の .new を削除します。

9.4. ファイル整合性ツール: AIDE および IMA

Red Hat Enterprise Linuxは、システム上のファイルとディレクトリの整合性をチェックおよび保持するためのさまざまなツールを提供します。次の表は、シナリオに適したツールを決定するのに役立ちます。

表9.1 AIDEとIMAの比較

比較項目Advanced Intrusion Detection Environment (AIDE)Integrity Measurement Architecture (IMA)

確認対象

AIDEは、システム上のファイルとディレクトリのデータベースを作成するユーティリティです。このデータベースは、ファイルの整合性をチェックし、侵入を検出するのに役立ちます。

IMAは、以前に保存された拡張属性と比較してファイル測定値(ハッシュ値)をチェックすることにより、ファイルが変更されているかどうかを検出します。

確認方法

AIDEはルールを使用して、ファイルとディレクトリの整合性状態を比較します。

IMAは、ファイルハッシュ値を使用して侵入を検出します。

理由

検出- AIDEは、ルールを検証することにより、ファイルが変更されているかどうかを検出します。

検出と防止- IMAは、ファイルの拡張属性を置き換えることにより、攻撃を検出および防止します。

用途

AIDEは、ファイルまたはディレクトリが変更されたときに脅威を検出します。

誰かがファイル全体の変更を試みた時に、IMAは脅威を検出します。

範囲

AIDEは、ローカルシステム上のファイルとディレクトリの整合性をチェックします。

IMAは、ローカルシステムとリモートシステムのセキュリティを確保します。

第10章 LUKS を使用したブロックデバイスの暗号化

ディスクの暗号化は、それを暗号化することにより、ブロックデバイス上のデータを保護します。デバイスで復号したコンテンツにアクセスするには、パスフレーズまたは鍵を認証として提供する必要があります。これは、モバイルコンピューターや、リムーバブルメディアの場合に特に重要になります。これにより、デバイスをシステムから物理的に削除した場合でも、デバイスのコンテンツを保護するのに役立ちます。LUKS 形式は、RHEL におけるブロックデバイスの暗号化のデフォルト実装です。

10.1. LUKS ディスクの暗号化

LUKS (Linux Unified Key Setup-on-disk-format) は、ブロックデバイスを暗号化でき、暗号化したデバイスの管理を簡素化するツールセットを提供します。LUKS を使用すれば、複数のユーザー鍵が、パーティションのバルク暗号化に使用されるマスター鍵を複号できるようになります。

RHEL は、LUKS を使用してブロックデバイスの暗号化を行います。デフォルトではインストール時に、ブロックデバイスを暗号化するオプションが指定されていません。ディスクを暗号化するオプションを選択すると、コンピューターを起動するたびにパスフレーズの入力が求められます。このパスフレーズは、パーティションの複号に用いられるバルク暗号化鍵のロックを解除します。デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。

LUKS の機能

  • LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツを保護するのに適しています。
  • 暗号化されたブロックデバイスの基本的な内容は任意であり、スワップデバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
  • LUKS は、既存のデバイスマッパーのカーネルサブシステムを使用します。
  • LUKS はパスフレーズのセキュリティーを強化し、辞書攻撃から保護します。
  • LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使用してバックアップキーやパスフレーズを追加できます。

LUKS が 行わない こと

  • LUKS などのディスク暗号化ソリューションは、システムの停止時にしかデータを保護しません。システムの電源がオンになり、LUKS がディスクを復号すると、そのディスクのファイルは、通常、そのファイルにアクセスできるすべてのユーザーが使用できます。
  • LUKS は、多くのユーザーが、同じデバイスにアクセスする鍵をそれぞれ所有することが必要となるシナリオには適していません。LUKS1 形式は鍵スロットを 8 個提供し、LUKS2 形式は鍵スロットを最大 32 個提供します。
  • LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。

暗号化

LUKS に使用されるデフォルトの暗号は aes-xts-plain64 です。LUKS のデフォルトの鍵サイズは 512 ビットです。Anaconda (XTS モード) を使用した LUKS のデフォルトの鍵サイズは 512 ビットです。利用可能な暗号は以下のとおりです。

  • AES: Advanced Encryption Standard
  • Twofish (128 ビットブロック暗号)
  • Serpent

10.2. RHEL の LUKS バージョン

RHEL では、LUKS 暗号化のデフォルト形式は LUKS2 です。従来の LUKS1 形式は、完全にサポートされ、以前の RHEL リリースと互換性のある形式として提供されます。

LUKS2 形式は、今後も、バイナリー構造を変更することなく、さまざまな要素を更新できるように設計されています。LUKS2 は、内部的にメタデータに JSON テキスト形式を使用し、メタデータの冗長性を提供し、メタデータの破損を検出し、メタデータコピーからの自動修正を可能にします。

重要

LUKS1 にのみ対応する以前のシステムとの互換性を必要とするシステムでは、LUKS2 を使用しないでください。RHEL 7 は、バージョン 7.6 以降の LUKS2 形式に対応していることに注意してください。

警告

LUKS2 および LUKS1 は、異なるコマンドを使用してディスクを暗号化します。LUKS バージョンに誤ったコマンドを使用すると、データが失われる可能性があります。

LUKS バージョン暗号化コマンド

LUKS2

cryptsetup reencrypt

LUKS1

cryptsetup-reencrypt

オンラインの再暗号化

LUKS2 形式は、デバイスが使用中の間に、暗号化したデバイスの再暗号化に対応します。たとえば、以下のタスクを実行するにあたり、デバイスでファイルシステムをアンマウントする必要はありません。

  • ボリュームキーの変更
  • 暗号化アルゴリズムの変更

暗号化されていないデバイスを暗号化する場合は、ファイルシステムのマウントを解除する必要があります。暗号化の短い初期化後にファイルシステムを再マウントできます。

LUKS1 形式は、オンライン再暗号化に対応していません。

変換

LUKS2 形式は、LUKS1 により提供されます。特定の状況では、LUKS1 を LUKS2 に変換できます。具体的には、以下のシナリオでは変換ができません。

  • LUKS1 デバイスが、Policy-Based Decryption (PBD - Clevis) ソリューションにより使用されているとマークされている。cryptsetup ツールは、luksmeta メタデータが検出されると、そのデバイスを変換することを拒否します。
  • デバイスがアクティブになっている。デバイスが非アクティブ状態でなければ、変換することはできません。

10.3. LUKS2 再暗号化中のデータ保護のオプション

LUKS2 では、再暗号化プロセスで、パフォーマンスやデータ保護の優先度を設定する複数のオプションを選択できます。

checksum

これがデフォルトのモードです。データ保護とパフォーマンスのバランスを取ります。

このモードは、セクターの個々のチェックサムを再暗号化領域に保存するため、復旧プロセスでは、LUKS2 がすでに再暗号化しているセクターを検出できます。このモードでは、ブロックデバイスセクターの書き込みがアトミックである必要があります。

journal
このモードが最も安全ですが、最も遅くなります。このモードは、バイナリー領域の再暗号化領域をジャーナル化するため、LUKS2 はデータを 2 回書き込みます。
none
このモードはパフォーマンスを優先し、データ保護は提供しません。これは、SIGTERM シグナルや、Ctrl+C を押すユーザーなど、安全なプロセス終了からのみデータを保護します。予期しないシステムクラッシュやアプリケーションのクラッシュが発生すると、データが破損する可能性があります。

cryptsetup--resilience オプションを使用してモードを選択できます。

LUKS2 の再暗号化プロセスが強制的に突然終了した場合、LUKS2 は以下のいずれかの方法で復旧を実行できます。

  • 自動的に実行 (LUKS2 デバイスの次回のオープン動作時)。この動作は、cryptsetup open コマンドまたは systemd-cryptsetup でデバイスを割り当てると発生します。
  • LUKS2 デバイスで cryptsetup repair コマンドを使用して手動で実行。

10.4. LUKS2 を使用したブロックデバイスの既存データの暗号化

この手順では、LUKS2 形式を使用して、暗号化されていないデバイスの既存データを暗号化します。新しい LUKS ヘッダーは、デバイスのヘッドに保存されます。

前提条件

  • ブロックデバイスにファイルシステムが含まれている。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. 暗号化するデバイスにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

    # umount /dev/sdb1
  2. LUKS ヘッダーを保存するための空き容量を確認します。以下のいずれかのオプションを選択します。

    • 論理ボリュームを暗号化する場合は、以下のように、ファイルシステムのサイズを変更せずに、論理ボリュームを拡張できます。以下に例を示します。

      # lvextend -L+32M vg00/lv00
    • parted などのパーティション管理ツールを使用してパーティションを拡張します。
    • このデバイスのファイルシステムを縮小します。ext2、ext3、または ext4 のファイルシステムには resize2fs ユーティリティーを使用できます。XFS ファイルシステムは縮小できないことに注意してください。
  3. 暗号化を初期化します。以下に例を示します。

    # cryptsetup reencrypt \
                 --encrypt \
                 --init-only \
                 --reduce-device-size 32M \
                 /dev/sdb1 sdb1_encrypted

    このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

  4. デバイスをマウントします。

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  5. オンライン暗号化を開始します。

    # cryptsetup reencrypt --resume-only /dev/sdb1

関連情報

  • cryptsetup (8)lvextend (8)resize2fs(8)、および parted(8) の man ページ

10.5. 独立したヘッダーがある LUKS2 を使用してブロックデバイスの既存データの暗号化

この手順では、LUKS ヘッダーを保存するための空き領域を作成せずに、ブロックデバイスの既存データを暗号化します。ヘッダーは、追加のセキュリティー層としても使用できる、独立した場所に保存されます。この手順では、LUKS2 暗号化形式を使用します。

前提条件

  • ブロックデバイスにファイルシステムが含まれている。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. プールにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

    # umount /dev/sdb1
  2. 暗号化を初期化します。

    # cryptsetup reencrypt \
                 --encrypt \
                 --init-only \
                 --header /path/to/header \
                 /dev/sdb1 sdb1_encrypted

    /path/to/header を、独立した LUKS ヘッダーのあるファイルへのパスに置き換えます。暗号化したデバイスを後でアンロックできるように、接続解除した LUKS ヘッダーにアクセスできる必要があります。

    このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

  3. デバイスをマウントします。

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  4. オンライン暗号化を開始します。

    # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

関連情報

  • cryptsetup(8) の man ページ

10.6. LUKS2 を使用した空のブロックデバイスの暗号化

この手順では、LUKS2 形式を使用して空のブロックデバイスを暗号化する方法を説明します。

前提条件

  • 空のブロックデバイス。

手順

  1. 暗号化した LUKS パーティションとしてパーティションを設定します。

    # cryptsetup luksFormat /dev/sdb1
  2. 暗号化した LUKS パーティションを開きます。

    # cryptsetup open /dev/sdb1 sdb1_encrypted

    これにより、パーティションのロックが解除され、デバイスマッパーを使用して新しいデバイスにマッピングされます。これは、 デバイス が暗号化されたデバイスであり、暗号化されたデータを上書きしないように /dev/mapper/device_mapped_name を使用して LUKS を通じてアドレス指定する必要があることをカーネルに警告します。

  3. パーティションに暗号化されたデータを書き込むには、デバイスをマッピングした名前でアクセスする必要があります。これを実行するには、ファイルシステムを作成する必要があります。以下に例を示します。

    # mkfs -t ext4 /dev/mapper/sdb1_encrypted
  4. デバイスをマウントします。

    # mount /dev/mapper/sdb1_encrypted mount-point

関連情報

  • cryptsetup(8) の man ページ

10.7. Storage システムロールを使用した LUKS 暗号化ボリュームの作成

Storage ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。

前提条件

  • Crypto Policies システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • Ansible Core が他のシステムを設定するシステムである制御ノードへのアクセスと許可。

    コントロールノードに、

    • ansible-core パッケージおよび rhel-system-roles パッケージがインストールされている。
重要

RHEL 8.0-8.5 は、Ansible に基づく自動化用に Ansible Engine 2.9 が含まれる別の Ansible リポジトリーへのアクセスを提供していました。Ansible Engine には、ansibleansible-playbookdockerpodman などのコネクター、多くのプラグインやモジュールなどのコマンドラインユーティリティーが含まれます。Ansible Engine の取得およびインストール方法の詳細は、ナレッジベースの記事「 How to download and install Red Hat Ansible Engine 」を参照してください。

RHEL 8.6 および 9.0 では、Ansible Core が導入されました( ansible-core パッケージとして提供)。これには、Ansible コマンドラインユーティリティー、コマンド、およびビルトイン Ansible プラグインの小規模なセットが含まれます。RHEL は AppStream リポジトリーを介してこのパッケージを提供し、サポート範囲が限定されています。詳細は、ナレッジベース の記事「RHEL 9 および RHEL 8.6 以降の AppStream リポジトリーに含まれる Ansible Core パッケージのサポート範囲」を参照し てください。

  • 管理対象ノードが記載されているインベントリーファイルがある。

手順

  1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

    - hosts: all
      vars:
        storage_volumes:
          - name: barefs
            type: disk
            disks:
             - sdb
            fs_type: xfs
            fs_label: label-name
            mount_point: /mnt/data
            encryption: true
            encryption_password: your-password
      roles:
       - rhel-system-roles.storage
  2. オプション:Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイル

第11章 ポリシーベースの復号を使用して暗号化ボリュームの自動アンロックの設定

ポリシーベースの暗号(PBD)は、物理マシンおよび仮想マシンでハードドライブの暗号化された root ボリュームおよびセカンダリーボリュームのロックを解除できるようにする一連の技術です。PBD は、ユーザーパスワード、TPM (Trusted Platform Module) デバイス、システムに接続する PKCS #11 デバイス (たとえばスマートカード) などのさまざまなロックの解除方法、もくしは特殊なネットワークサーバーを使用します。

PBD を使用すると、ポリシーにさまざまなロックの解除方法を組み合わせて、さまざまな方法で同じボリュームのロックを解除できるようにすることができます。RHEL における PBD の現在の実装は、Clevis フレームワークと、ピン と呼ばれるプラグインで構成されます。各ピンは、個別のアンロック機能を提供します。現在利用できるピンは以下のとおりです。

  • Tang - ネットワークサーバーを使用したボリュームのロックを解除可能
  • tpm2 - TPM2 ポリシーを使用してボリュームのロックを解除
  • SSS - Shamir's Secret Sharing(SSS)暗号化スキームを使用して高可用性システムをデプロイできるようにします。

NBDE (Network Bound Disc Encryption) は、特定のネットワークサーバーに暗号化ボリュームをバインドできるようにする PBD のサブカテゴリーです。NBDE の現在の実装には、Tang サーバーと、Tang サーバー用の Clevis ピンが含まれます。

11.1. NBDE (Network-Bound Disk Encryption)

Red Hat Enterprise Linux では、NBDE は、以下のコンポーネントおよび技術により実装されます。

図11.1 LUKS1 で暗号化したボリュームを使用する場合の NBDE スキーム(luksmeta パッケージは、LUKS2 ボリュームには使用されません)

RHEL Security Guide 453350 0717 ECE NBDE

Tang は、ネットワークのプレゼンスにデータをバインドするためのサーバーです。セキュリティーが保護された特定のネットワークにシステムをバインドする際に利用可能なデータを含めるようにします。Tang はステートレスで、TLS または認証は必要ありません。エスクローベースのソリューション (サーバーが暗号鍵をすべて保存し、使用されたことがあるすべての鍵に関する知識を有する) とは異なり、Tang はクライアントの鍵と相互作用することはないため、クライアントから識別情報を得ることがありません。

Clevis は、自動化された復号用のプラグイン可能なフレームワークです。NBDE では、Clevis は、LUKS ボリュームの自動アンロックを提供します。clevis パッケージは、クライアントで使用される機能を提供します。

Clevis ピン は、Clevis フレームワークへのプラグインです。このようなピンの 1 つは、NBDE サーバー (Tang) との相互作用を実装するプラグインです。

Clevis および Tang は、一般的なクライアントおよびサーバーのコンポーネントで、ネットワークがバインドされた暗号化を提供します。Clevis および Tang は、Red Hat Enterprise Linux で LUKS と組み合わせて、root および非 root のストレージボリュームの暗号化および複号に使用し、NBDE を実現します。

クライアントおよびサーバーのコンポーネントはともに José ライブラリーを使用して、暗号化および複号の操作を実行します。

NBDE のプロビジョニングを開始すると、Tang サーバーの Clevis ピンは、Tang サーバーの、アドバタイズされている非対称鍵の一覧を取得します。もしくは、鍵が非対称であるため、Tang の公開鍵の一覧を帯域外に配布して、クライアントが Tang サーバーにアクセスしなくても動作できるようにします。このモードは オフラインプロビジョニング と呼ばれます。

Tang 用の Clevis ピンは、公開鍵のいずれかを使用して、固有で、暗号論的に強力な暗号鍵を生成します。この鍵を使用してデータを暗号化すると、この鍵は破棄されます。Clevis クライアントは、使いやすい場所に、このプロビジョニング操作で生成した状態を保存する必要があります。データを暗号化するこのプロセスは プロビジョニング手順 と呼ばれています。

LUKS バージョン 2 (LUKS2) は、RHEL のデフォルトのディスク暗号化形式であるため、NBDE のプロビジョニング状態は、LUKS2 ヘッダーにトークンとして保存されます。luksmeta パッケージによる NBDE のプロビジョニング状態は、LUKS1 で暗号化したボリュームにのみ使用されます。

Tang 用の Clevis ピンは、規格を必要とせずに LUKS1 と LUKS2 の両方をサポートします。Clevisはプレーンテキストファイルを暗号化できますが、ブロックデバイスの暗号化にはcryptsetupツールを使用する必要があります。詳細については、 Encrypting block devices using LUKSを参照してください。

クライアントがそのデータにアクセスする準備ができると、プロビジョニング手順で生成したメタデータを読み込み、応答して暗号鍵を戻します。このプロセスは 復旧手順 と呼ばれます。

Clevis は、NBDE ではピンを使用して LUKS ボリュームをバインドしているため、自動的にロックが解除されます。バインドプロセスが正常に終了すると、提供されている Dracut アンロックを使用してディスクをアンロックできます。

注記

kdump カーネルクラッシュのダンプメカニズムが、システムメモリーのコンテンツを LUKS で暗号化したデバイスに保存するように設定されている場合には、2 番目のカーネル起動時にパスワードを入力するように求められます。

11.2. 暗号化クライアント (Clevis) のインストール

この手順に従って、システムに Clevis プラグ可能フレームワークを使用してデプロイと起動を行います。

手順

  1. 暗号化されたボリュームを持つシステムに Clevis とそのピンをインストールするには、次のコマンドを実行します。

    # dnf install clevis
  2. データを複号するには、clevis decrypt コマンドを実行して、JWE (JSON Web Encryption) 形式で暗号文を指定します。以下に例を示します。

    $ clevis decrypt < secret.jwe

関連情報

  • clevis(1) の man ページ
  • 引数を指定せずに clevis コマンドを実行した後の組み込み CLI ヘルプ

    $ clevis
    Usage: clevis COMMAND [OPTIONS]
    
    clevis decrypt      Decrypts using the policy defined at encryption time
    clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
    clevis encrypt tang Encrypts using a Tang binding server policy
    clevis encrypt tpm2 Encrypts using a TPM2.0 chip binding policy
    clevis luks bind    Binds a LUKS device using the specified policy
    clevis luks edit    Edit a binding from a clevis-bound slot in a LUKS device
    clevis luks list    Lists pins bound to a LUKSv1 or LUKSv2 device
    clevis luks pass    Returns the LUKS passphrase used for binding a particular slot.
    clevis luks regen   Regenerate clevis binding
    clevis luks report  Report tang keys' rotations
    clevis luks unbind  Unbinds a pin bound to a LUKS volume
    clevis luks unlock  Unlocks a LUKS volume

11.3. SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント

この手順では、Enforcing モードの SELinux で限定サービスとして、カスタムポートで実行する Tang サーバーをデプロイします。

前提条件

  • policycoreutils-python-utils パッケージおよび依存関係がインストールされている。
  • firewalld サービスが実行している。

手順

  1. tang パッケージとその依存関係をインストールするには、root で以下のコマンドを実行します。

    # dnf install tang
  2. 7500/tcp などの不要なポートを選択し、tangd サービスがそのポートにバインドできるようにします。

    # semanage port -a -t tangd_port_t -p tcp 7500

    ポートは 1 つのサービスのみで一度に使用できるため、すでに使用しているポートを使用しようとすると、ValueError: Port already defined エラーが発生します。

  3. ファイアウォールのポートを開きます。

    # firewall-cmd --add-port=7500/tcp
    # firewall-cmd --runtime-to-permanent
  4. tangd サービスを有効にします。

    # systemctl enable tangd.socket
  5. オーバーライドファイルを作成します。

    # systemctl edit tangd.socket
  6. 以下のエディター画面で、/etc/systemd/system/tangd.socket.d/ ディレクトリーにある空の override.conf ファイルを開き、次の行を追加して、Tang サーバーのデフォルトのポートを、80 から、以前取得した番号に変更します。

    [Socket]
    ListenStream=
    ListenStream=7500

    ファイルを保存して、エディターを終了します。

  7. 変更した設定を再読み込みします。

    # systemctl daemon-reload
  8. 設定が機能していることを確認します。

    # systemctl show tangd.socket -p Listen
    Listen=[::]:7500 (Stream)
  9. tangd サービスを開始します。

    # systemctl restart tangd.socket

    tangd が、systemd のソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、一組の暗号鍵が自動的に生成されます。鍵の手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。

関連情報

  • tang(8)semanage(8)firewall-cmd(1)jose(1)systemd.unit(5) および systemd.socket(5) の man ページ

11.4. Tang サーバーの鍵のローテーションおよびクライアントでのバインディングの更新

以下の手順に従って、Tang サーバーの鍵をローテーションし、クライアントの既存のバインディングを更新します。鍵をローテートするのに適した間隔は、アプリケーション、鍵のサイズ、および組織のポリシーにより異なります。

したがって、nbde_server RHEL システムロールを使用して、Tang 鍵をローテーションできます。詳細は「複数の Tang サーバー設定での nbde_server システムロールの使用」を参照してください。

前提条件

  • Tang サーバーが実行している。
  • clevis パッケージおよび clevis-luks パッケージがクライアントにインストールされている。

手順

  1. /var/db/tang 鍵データベースディレクトリーのすべての鍵の名前の前に . を指定して、アドバタイズメントに対して非表示にします。以下の例のファイル名は、Tang サーバーの鍵データベースディレクトリーにある一意のファイル名とは異なります。

    # cd /var/db/tang
    # ls -l
    -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
    # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
  2. 名前が変更され、Tang サーバーのアドバタイズに対してすべての鍵が非表示になっていることを確認します。

    # ls -l
    total 0
  3. Tang サーバーの /var/db/tang/usr/libexec/tangd-keygen コマンドを使用して新しい鍵を生成します。

    # /usr/libexec/tangd-keygen /var/db/tang
    # ls /var/db/tang
    3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk
  4. Tang サーバーが、以下のように新規キーペアから署名キーを公開していることを確認します。

    # tang-show-keys 7500
    3ZWS6-cDrCG61UPJS2BMmPU4I54
  5. NBDE クライアントで clevis luks report コマンドを使用して、Tang サーバーでアドバタイズされた鍵が同じままかどうかを確認します。clevis luks list コマンドを使用すると、関連するバインディングのあるスロットを特定できます。以下に例を示します。

    # clevis luks list -d /dev/sda2
    1: tang '{"url":"http://tang.srv"}'
    # clevis luks report -d /dev/sda2 -s 1
    ...
    Report detected that some keys were rotated.
    Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]
  6. 新しい鍵の LUKS メタデータを再生成するには、直前のコマンドプロンプトで y を押すか、clevis luks regen コマンドを使用します。

    # clevis luks regen -d /dev/sda2 -s 1
  7. すべての古いクライアントが新しい鍵を使用することを確認したら、Tang サーバーから古い鍵を削除できます。次に例を示します。

    # cd /var/db/tang
    # rm .*.jwk
警告

クライアントが使用している最中に古い鍵を削除すると、データが失われる場合があります。このような鍵を誤って削除した場合は、クライアントで clevis luks regen コマンドを実行し、LUKS パスワードを手動で提供します。

関連情報

  • tang-show-keys(1)clevis-luks-list(1)clevis-luks-report(1)、および clevis-luks-regen(1) の man ページ

11.5. Web コンソールで Tang 鍵を使用した自動アンロックの設定

Tang サーバーが提供する鍵を使用して、LUKS で暗号化したストレージデバイスの自動ロック解除を設定します。

前提条件

  • RHEL 9 Web コンソールがインストールされている。

    詳細については、Installing the web console参照してください。

  • cockpit-storaged パッケージがシステムにインストールされている。
  • cockpit.socket サービスがポート 9090 で実行されている。
  • clevis パッケージ、tang パッケージ、および clevis-dracut パッケージがインストールされている。
  • Tang サーバーが実行している。

手順

  1. Web ブラウザーに以下のアドレスを入力して、RHEL Web コンソールを開きます。

    https://localhost:9090

    リモートシステムに接続する際に、localhost の部分をリモートサーバーのホスト名または IP アドレスに置き換えます。

  2. 認証情報を指定して、ストレージ をクリックします。&gt ; をクリックして、Tang サーバーを使用してロックを解除する暗号化デバイスの詳細を展開し、Encryption をクリックします。
  3. Keys セクションの + をクリックして Tang キーを追加します。

    RHEL web コンソール:暗号化
  4. Tang サーバーのアドレスと、LUKS で暗号化したデバイスのロックを解除するパスワードを指定します。Add をクリックして確定します。

    RHEL web コンソール:Tang キーの追加

    以下のダイアログウインドウは、鍵ハッシュが一致することを確認するコマンドを提供します。

  5. Tang サーバーの端末で、tang-show-keys コマンドを使用して、比較用の鍵ハッシュを表示します。この例では、Tang サーバーがポート 7500 で実行されています。

    # tang-show-keys 7500
    fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM
  6. Web コンソールと前述のコマンドの出力のキーハッシュが同じ場合は、Trust key をクリックします。

    RHEL web コンソール:Tang キーの検証
  7. 初期ブートシステムでディスクバインディングを処理できるようにするには、左側のナビゲーションバーの下部にある Terminal をクリックし、次のコマンドを入力します。

    # dnf install clevis-dracut
    # grubby --update-kernel=ALL --args="rd.neednet=1"
    # dracut -fv --regenerate-all
  8. Clevis で、ブートプロセスでマウントするボリュームもアンロックできるようにするには、システムを再起動する前に、クライアントで以下のコマンドを使用します。

    # systemctl enable clevis-luks-askpass.path

検証

  1. 新規に追加された Tang キーが Keyserver タイプの Keys セクションに一覧表示されていることを確認します。

    RHEL web コンソール:キーサーバーキーが一覧表示されます
  2. バインディングが初期ブートで使用できることを確認します。次に例を示します。

    # lsinitrd | grep clevis
    clevis
    clevis-pin-sss
    clevis-pin-tang
    clevis-pin-tpm2
    -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
    -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
    ...
    -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
    -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

11.6. 基本的なNBDEおよびTPM2暗号化クライアント操作

Clevisフレームワークは、プレーンテキストファイルを暗号化し、JSON Web Encryption (JWE)形式の暗号化テキストとLUKS暗号化ブロックデバイスの両方を復号できます。Clevisクライアントは、暗号化操作にTangネットワークサーバーまたはTrusted Platform Module 2.0(TPM 2.0)チップのいずれかを使用できます。

次のコマンドは、プレーンテキストファイルが含まれる例でClevisが提供する基本的な機能を示しています。また、NBDEまたはClevis + TPMのデプロイメントのトラブルシューティングにも使用できます。

Tangサーバーにバインドされた暗号化クライアント

  • Clevis 暗号化クライアントが Tang サーバーにバインドサれることを確認するには、clevis encrypt tang サブコマンドを使用します。

    $ clevis encrypt tang '{"url":"http://tang.srv:port"}' < input-plain.txt > secret.jwe
    The advertisement contains the following signing keys:
    
    _OsIk0T-E2l6qjfdDiwVmidoZjA
    
    Do you wish to trust these keys? [ynYN] y

    この例の URL (http://tang.srv:port) を、 tang がインストールされているサーバーの URL に変更します。secret.jwe 出力ファイルには、JWE形式で暗号化した暗号文が含まれます。この暗号文は input-plain.txt 入力ファイルから読み込まれます。

    また、構成に SSH アクセスなしで Tang サーバーとの非対話型の通信が必要な場合は、アドバタイズメントをダウンロードしてファイルに保存できます。

    $ curl -sfg http://tang.srv:port/adv -o adv.jws

    ファイルやメッセージの暗号化など、次のタスクには adv.jws ファイルのアドバタイズメントを使用します。

    $ echo 'hello' | clevis encrypt tang '{"url":"http://tang.srv:port","adv":"adv.jws"}'
  • データを複号するには、clevis decrypt コマンドを実行して、暗号文 (JWE) を提供します。

    $ clevis decrypt < secret.jwe > output-plain.txt

TPM2.0を使用する暗号化クライアント

  • TPM 2.0 チップを使用して暗号化するには、JSON 設定オブジェクト形式の引数のみが使用されている clevis encrypt tpm2 サブコマンドを使用します。

    $ clevis encrypt tpm2 '{}' < input-plain.txt > secret.jwe

    別の階層、ハッシュ、および鍵アルゴリズムを選択するには、以下のように、設定プロパティーを指定します。

    $ clevis encrypt tpm2 '{"hash":"sha256","key":"rsa"}' < input-plain.txt > secret.jwe
  • データを復号するには、JSON Web Encryption (JWE) 形式の暗号文を提供します。

    $ clevis decrypt < secret.jwe > output-plain.txt

ピンは、PCR (Platform Configuration Registers) 状態へのデータのシーリングにも対応します。このように、PCP ハッシュ値が、シーリング時に使用したポリシーと一致する場合にのみ、データのシーリングを解除できます。

たとえば、SHA-256 バンクのインデックス 0 および 7 を使用してデータを PCR に封印するには、次のようにします。

$ clevis encrypt tpm2 '{"pcr_bank":"sha256","pcr_ids":"0,7"}' < input-plain.txt > secret.jwe
警告

PCRのハッシュは書き換えることができ、暗号化されたボリュームのロックを解除することはできなくなりました。このため、PCRの値が変更された場合でも、暗号化されたボリュームのロックを手動で解除できる強力なパスフレーズを追加します。

shim-x64パッケージのアップグレード後にシステムが暗号化されたボリュームのロックを自動的に解除できない場合は、KCSの記事Clevis TPM2 no longer decrypts LUKS devices after a restartの手順に従ってください。

関連情報

  • clevis-encrypt-tang(1)clevis-luks-unlockers(7)clevis(1)、および clevis-encrypt-tpm2(1) の man ページ
  • 以下のように引数指定せずに clevisclevis decrypt および clevis encrypt tang コマンドを入力したときに表示される組み込み CLI。

    $ clevis encrypt tang
    Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE
    ...

11.7. LUKS で暗号化したボリュームの手動登録の設定

以下の手順に従って、NBDE を使用して LUKS で暗号化されたボリュームのロック解除を設定します。

前提条件

  • Tang サーバーが実行されていて、使用できるようにしてある。

手順

  1. LUKS で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの clevis-luks をインストールします。

    # dnf install clevis-luks
  2. PBD 用 LUKS 暗号化ボリュームを特定します。次の例では、ブロックデバイスは /dev/sda2 と呼ばれています。

    # lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                                             8:0    0    12G  0 disk
    ├─sda1                                          8:1    0     1G  0 part  /boot
    └─sda2                                          8:2    0    11G  0 part
      └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
        ├─rhel-root                               253:0    0   9.8G  0 lvm   /
        └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]
  3. clevis luks bind コマンドを使用して、ボリュームを Tang サーバーにバインドします。

    # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
    The advertisement contains the following signing keys:
    
    _OsIk0T-E2l6qjfdDiwVmidoZjA
    
    Do you wish to trust these keys? [ynYN] y
    You are about to initialize a LUKS device for metadata storage.
    Attempting to initialize it may result in data loss if data was
    already written into the LUKS header gap in a different format.
    A backup is advised before initialization is performed.
    
    Do you wish to initialize /dev/sda2? [yn] y
    Enter existing LUKS password:

    このコマンドは、以下の 4 つの手順を実行します。

    1. LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
    2. Clevis で新しい鍵を暗号化します。
    3. LUKS2 ヘッダートークンに Clevis JWE オブジェクトを保存するか、デフォルト以外の LUKS1 ヘッダーが使用されている場合は LUKSMeta を使用します。
    4. LUKS を使用する新しい鍵を有効にします。
    注記

    バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

    ボリュームは、現在、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。

  4. Clevis で、ブートプロセスでマウントするボリュームもアンロックできるようにするには、システムを再起動する前に、クライアントで以下のコマンドを使用します。

    # systemctl enable clevis-luks-askpass.path
  5. システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで dracut ツールを使用します。

    # dnf install clevis-dracut

    RHEL では、Clevis はホスト固有の設定オプションを指定せずに汎用 initrd (initial ramdisk)を生成し、カーネルコマンドラインに rd.neednet=1 などのパラメーターを自動的に追加しません。初期の起動時にネットワークを必要とする Tang ピンを使用する場合は、--hostonly-cmdline 引数を使用し、dracut が Tang バインディングを検出すると rd.neednet=1 を追加します。

    # dracut -fv --regenerate-all --hostonly-cmdline

    または、/etc/dracut.conf.d/ に .conf ファイルを作成し、以下のように hostonly_cmdline=yes オプションを追加します。

    # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf
    注記

    Clevis がインストールされているシステムで grubby ツールを使用して、システム起動時の早い段階で Tang ピンのネットワークを利用できるようにすることができます。

    # grubby --update-kernel=ALL --args="rd.neednet=1"

    次に、--hostonly-cmdline なしで dracut を使用できます。

    # dracut -fv --regenerate-all

検証

  1. Clevis JWE オブジェクトが LUKS ヘッダーに適切に置かれていることを確認するには、clevis luks list コマンドを使用します。

    # clevis luks list -d /dev/sda2
    1: tang '{"url":"http://tang.srv:port"}'
重要

(DHCP を使用しない) 静的な IP 設定を持つクライアントに NBDE を使用するには、以下のように、手動でネットワーク設定を dracut ツールに渡します。

# dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none"

もしくは、静的ネットワーク情報を使用して /etc/dracut.conf.d/ ディレクトリーに .conf ファイルを作成します。以下に例を示します。

# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none"

初期 RAM ディスクイメージを再生成します。

# dracut -fv --regenerate-all

関連情報

11.8. TPM2.0ポリシーを使用したLUKS で暗号化したボリュームの手動登録の設定

次の手順を使用して、Trusted Platform Module 2.0 (TPM 2.0)ポリシーを使用してLUKS暗号化ボリュームのロック解除を設定します。

前提条件

  • アクセス可能なTPM2.0互換デバイス。
  • システムが 64 ビット Intel アーキテクチャー、または 64 ビット AMD アーキテクチャーである。

手順

  1. LUKS で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの clevis-luks をインストールします。

    # dnf install clevis-luks
  2. PBD 用 LUKS 暗号化ボリュームを特定します。次の例では、ブロックデバイスは /dev/sda2 と呼ばれています。

    # lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                                             8:0    0    12G  0 disk
    ├─sda1                                          8:1    0     1G  0 part  /boot
    └─sda2                                          8:2    0    11G  0 part
      └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
        ├─rhel-root                               253:0    0   9.8G  0 lvm   /
        └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]
  3. clevis luks bind コマンドを使用して、ボリュームを TPM 2.0 デバイスにバインドします。以下に例を示します。

    # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
    ...
    Do you wish to initialize /dev/sda2? [yn] y
    Enter existing LUKS password:

    このコマンドは、以下の 4 つの手順を実行します。

    1. LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
    2. Clevis で新しい鍵を暗号化します。
    3. LUKS2 ヘッダートークンに Clevis JWE オブジェクトを保存するか、デフォルト以外の LUKS1 ヘッダーが使用されている場合は LUKSMeta を使用します。
    4. LUKS を使用する新しい鍵を有効にします。

      注記

      バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

      あるいは、特定のPlatform Configuration Registers (PCR)の状態にデータをシールする場合は、clevis luks bindコマンドにpcr_bankpcr_ids値を追加します。以下に例を示します。

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"0,1"}'
      警告

      PCRハッシュ値がシール時に使用されるポリシーと一致し、ハッシュを書き換えることができる場合にのみ、データをアンシールできるため、PCRの値が変更された場合、暗号化されたボリュームのロックを手動で解除できる強力なパスフレーズを追加します。

      shim-x64パッケージのアップグレード後にシステムが暗号化されたボリュームのロックを自動的に解除できない場合は、KCSの記事Clevis TPM2 no longer decrypts LUKS devices after a restartの手順に従ってください。

  4. ボリュームは、現在、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。
  5. システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで dracut ツールを使用します。

    # dnf install clevis-dracut
    # dracut -fv --regenerate-all

検証

  1. Clevis JWE オブジェクトが LUKS ヘッダーに適切に置かれていることを確認するには、clevis luks list コマンドを使用します。

    # clevis luks list -d /dev/sda2
    1: tpm2 '{"hash":"sha256","key":"rsa"}'

関連情報

  • clevis-luks-bind(1)clevis-encrypt-tpm2(1)、および dracut.cmdline(7) の man ページ

11.9. LUKS で暗号化したボリュームからの Clevis ピンの手動削除

clevis luks bind コマンドで作成されたメタデータを手動で削除する場合や、Clevis が追加したパスフレーズを含む鍵スロットを一掃するには、以下の手順を行います。

重要

LUKS で暗号化したボリュームから Clevis ピンを削除する場合は、clevis luks unbind コマンドを使用することが推奨されます。clevis luks unbind を使用した削除手順は、1 回のステップで構成され、LUKS1 ボリュームおよび LUKS2 ボリュームの両方で機能します。以下のコマンド例は、バインディング手順で作成されたメタデータを削除し、/dev/sda2 デバイスの鍵スロット 1 を削除します。

# clevis luks unbind -d /dev/sda2 -s 1

前提条件

  • Clevis バインディングを使用した LUKS 暗号化ボリューム。

手順

  1. /dev/sda2 などのボリュームがどの LUKS バージョンであるかを確認し、Clevis にバインドされているスロットおよびトークンを特定します。

    # cryptsetup luksDump /dev/sda2
    LUKS header information
    Version:        2
    ...
    Keyslots:
      0: luks2
    ...
    1: luks2
          Key:        512 bits
          Priority:   normal
          Cipher:     aes-xts-plain64
    ...
          Tokens:
            0: clevis
                  Keyslot:  1
    ...

    上記の例では、Clevis トークンは 0 で識別され、関連付けられた鍵スロットは 1 です。

  2. LUKS2 暗号化の場合は、トークンを削除します。

    # cryptsetup token remove --token-id 0 /dev/sda2
  3. デバイスを LUKS1 で暗号化し、cryptsetup luksDump コマンドの出力に Version: 文字列が示されている場合は、luksmeta wipe コマンドでこの追加手順を行います。

    # luksmeta wipe -d /dev/sda2 -s 1
  4. Clevis パスフレーズを含む鍵スロットを削除します。

    # cryptsetup luksKillSlot /dev/sda2 1

関連情報

  • clevis-luks-unbind(1)cryptsetup(8)、および luksmeta(8) の man ページ

11.10. キックスタートを使用して、LUKS で暗号化したボリュームの自動登録の設定

この手順に従って、LUKS で暗号化されたボリュームの登録に Clevis を使用する自動インストールプロセスを構成します。

手順

  1. 一時パスワードを使用して、LUKS 暗号化が有効になっているディスクを、/boot 以外のすべてのマウントポイントで分割するように、キックスタートに指示します。パスワードは、登録プロセスの手順に使用するための一時的なものです。

    part /boot --fstype="xfs" --ondisk=vda --size=256
    part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

    OSPP 準拠のシステムには、より複雑な構成が必要であることに注意してください。次に例を示します。

    part /boot --fstype="xfs" --ondisk=vda --size=256
    part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
    part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
    part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
  2. 関連する Clevis パッケージを %packages セクションに追加して、インストールします。

    %packages
    clevis-dracut
    clevis-luks
    clevis-systemd
    %end
  3. オプションで、必要に応じて暗号化されたボリュームのロックを手動で解除できるようにするには、一時パスフレーズを削除する前に強力なパスフレーズを追加します。詳細については、How to add a passphrase, key, or keyfile to an existing LUKS deviceの記事を参照してください。
  4. clevis luks bind を呼び出して、%post セクションのバインディングを実行します。その後、一時パスワードを削除します。

    %post
    clevis luks bind -y -k - -d /dev/vda2 \
    tang '{"url":"http://tang.srv"}' <<< "temppass"
    cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
    dracut -fv --regenerate-all
    %end

    設定が起動初期にネットワークを必要とするTangピンに依存している場合、または静的IP設定のNBDEクライアントを使用している場合は、Configuring manual enrollment of LUKS-encrypted volumesに従ってdracutコマンドを変更する必要があります。

    clevis luks bindコマンドの-yオプションは、RHEL 8.3から使用できることに注意してください。RHEL 8.2以前では、 clevis luks bindコマンドで-y-fに置き換え、Tangサーバーからアドバタイズメントをダウンロードします。

    %post
    curl -sfg http://tang.srv/adv -o adv.jws
    clevis luks bind -f -k - -d /dev/vda2 \
    tang '{"url":"http://tang.srv","adv":"adv.jws"}' <<< "temppass"
    cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
    dracut -fv --regenerate-all
    %end
    警告

    cryptsetup luksRemoveKey コマンドは、それを適用する LUKS2 デバイスがそれ以上に管理されるのを防ぎます。LUKS1 デバイスに対してのみ dmsetup コマンドを使用して、削除されたマスターキーを回復できます。

Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、同様の手順を使用できます。

関連情報

11.11. LUKS で暗号化されたリムーバブルストレージデバイスの自動アンロックの設定

この手順に従って、LUKS 暗号化 USB ストレージデバイスの自動ロック解除プロセスを設定します。

手順

  1. USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。

    # dnf install clevis-udisks2
  2. システムを再起動し、「LUKS で暗号化したボリュームの手動登録の設定」に従って、clevis luks bind コマンドを使用したバインディング手順を実行します。以下に例を示します。

    # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'
  3. LUKS で暗号化したリムーバブルデバイスは、GNOME デスクトップセッションで自動的にアンロックできるようになりました。Clevis ポリシーにバインドするデバイスは、clevis luks unlock コマンドでアンロックできます。

    # clevis luks unlock -d /dev/sdb1

Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、同様の手順を使用できます。

関連情報

  • clevis-luks-unlockers(7) man ページ

11.12. 高可用性 NBDE システムのデプロイメント

Tang は、高可用性デプロイメントを構築する方法を 2 つ提供します。

クライアントの冗長性 (推奨)
クライアントは、複数の Tang サーバーにバインドする機能を使用して設定する必要があります。この設定では、各 Tang サーバーに独自の鍵があり、クライアントは、このサーバーのサブセットに接続することで復号できます。Clevis はすでに、sss プラグインを使用してこのワークフローに対応しています。Red Hat は、高可用性のデプロイメントにこの方法を推奨します。
鍵の共有
冗長性を確保するために、Tang のインスタンスは複数デプロイできます。2 つ目以降のインスタンスを設定するには、tang パッケージをインストールし、SSH 経由で rsync を使用してその鍵ディレクトリーを新規ホストにコピーします。鍵を共有すると鍵への不正アクセスのリスクが高まり、追加の自動化インフラストラクチャーが必要になるため、Red Hat はこの方法を推奨していません。

11.12.1. シャミアの秘密分散を使用した高可用性 NBDE

シャミアの秘密分散 (SSS) は、秘密を複数の固有のパーツに分割する暗号スキームです。秘密を再構築するには、いくつかのパーツが必要になります。数値はしきい値と呼ばれ、SSS はしきい値スキームとも呼ばれます。

Clevis は、SSS の実装を提供します。鍵を作成し、これをいくつかのパーツに分割します。各パーツは、SSS も再帰的に含む別のピンを使用して暗号化されます。また、しきい値 t も定義します。NBDE デプロイメントで少なくとも t の部分を復号すると、暗号化鍵が復元され、復号プロセスが成功します。Clevis がしきい値で指定されている数よりも小さい部分を検出すると、エラーメッセージが出力されます。

11.12.1.1. 例 1:2 台の Tang サーバーを使用した冗長性

次のコマンドは、2 台の Tang サーバーのうち少なくとも 1 台が使用可能な場合に、LUKS で暗号化されたデバイスを復号します。

# clevis luks bind -d /dev/sda1 sss '{"t":1,"pins":{"tang":[{"url":"http://tang1.srv"},{"url":"http://tang2.srv"}]}}'

上記のコマンドでは、以下の設定スキームを使用していました。

{
    "t":1,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            },
            {
                "url":"http://tang2.srv"
            }
        ]
    }
}

この設定では、一覧に記載されている 2 台の tang サーバーのうち少なくとも 1 つが利用可能であれば、SSS しきい値 t1 に設定され、clevis luks bind コマンドが秘密を正常に再構築します。

11.12.1.2. 例 2:Tang サーバーと TPM デバイスで共有している秘密

次のコマンドは、tang サーバーと tpm2 デバイスの両方が利用可能な場合に、LUKS で暗号化したデバイスを正常に復号します。

# clevis luks bind -d /dev/sda1 sss '{"t":2,"pins":{"tang":[{"url":"http://tang1.srv"}], "tpm2": {"pcr_ids":"0,7"}}}'

SSS しきい値「t」が「2」に設定されている設定スキームは以下のようになります。

{
    "t":2,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            }
        ],
        "tpm2":{
            "pcr_ids":"0,7"
        }
    }
}

関連情報

  • tang(8) (High Availability セクション)、clevis(1) (Shamir's Secret Sharing セクション)、および clevis-encrypt-sss(1) の man ページ

11.13. NBDE ネットワークで仮想マシンのデプロイメント

clevis luks bind コマンドは、LUKS マスター鍵を変更しません。これは、仮想マシンまたはクラウド環境で使用する LUKS で暗号化したイメージを作成する場合に、このイメージを実行するすべてのインスタンスがマスター鍵を共有することを意味します。これにはセキュリティーの観点で大きな問題があるため、常に回避する必要があります。

これは、Clevis の制限ではなく、LUKS の設計原理です。クラウドに暗号化された root ボリュームが必要な場合は、クラウド内の Red Hat Enterprise Linux の各インスタンスに対してインストールプロセス(通常はキックスタートを使用)を実行します。このイメージは、LUKS マスター鍵を共有しなければ共有できません。

仮想化環境に自動アンロックをデプロイするには、キックスタートファイルとともに loraxvirt-install などのシステムを使用します(「キックスタートを 使用した LUKS で暗号化したボリュームの自動登録の設定」を参照)。または、暗号化した各仮想マシンが固有のマスターキーを持つようにする自動プロビジョニングツールを使用します。

関連情報

  • clevis-luks-bind(1) man ページ

11.14. NBDE を使用してクラウド環境に自動的に登録可能な仮想マシンイメージの構築

自動登録可能な暗号化イメージをクラウド環境にデプロイすると、特有の課題が発生する可能性があります。他の仮想化環境と同様に、LUKS マスター鍵を共有しないように、1 つのイメージから起動するインスタンス数を減らすことが推奨されます。

したがって、ベストプラクティスは、どのパブリックリポジトリーでも共有されず、限られたインスタンスのデプロイメントのベースを提供するように、イメージをカスタマイズすることです。作成するインスタンスの数は、デプロイメントのセキュリティーポリシーで定義する必要があります。また、LUKS マスター鍵の攻撃ベクトルに関連するリスク許容度に基づいて決定する必要があります。

LUKS に対応する自動デプロイメントを構築するには、Lorax、virt-install などのシステムとキックスタートファイルを一緒に使用し、イメージ構築プロセス中にマスター鍵の一意性を確保する必要があります。

クラウド環境では、ここで検討する 2 つの Tang サーバーデプロイメントオプションが利用できます。まず、クラウド環境そのものに Tang サーバーをデプロイできます。もしくは、2 つのインフラストラクチャー間で VPN リンクを使用した独立したインフラストラクチャーで、クラウドの外に Tang サーバーをデプロイできます。

クラウドに Tang をネイティブにデプロイすると、簡単にデプロイできます。ただし、別のシステムの暗号文のデータ永続化層でインフラストラクチャーを共有します。Tang サーバーの秘密鍵および Clevis メタデータは、同じ物理ディスクに保存できる場合があります。この物理ディスクでは、暗号文データへのいかなる不正アクセスが可能になります。

重要

このため、Red Hat は、データを保存する場所と、Tang が実行しているシステムを、物理的に分離させることを強く推奨します。クラウドと Tang サーバーを分離することで、Tang サーバーの秘密鍵が、Clevis メタデータと誤って結合することがないようにします。さらに、これにより、クラウドインフラストラクチャーが危険にさらされている場合に、Tang サーバーのローカル制御を提供します。

11.15. コンテナーとしての Tang のデプロイ

tang コンテナーイメージは、OpenShift Container Platform (OCP) クラスターまたは別の仮想マシンで実行する Clevis クライアントの Tang-server 復号化機能を提供します。

前提条件

  • podman パッケージとその依存関係がシステムにインストールされている。
  • podman login registry.redhat.io コマンドを使用して registry.redhat.io コンテナーカタログにログインしている。詳細は、「Red Hat コンテナーレジストリーの認証」を参照してください。
  • Clevis クライアントは、Tang サーバーを使用して、自動的にアンロックする LUKS で暗号化したボリュームを含むシステムにインストールされている。

手順

  1. registry.redhat.io レジストリーから tang コンテナーイメージをプルします。

    # podman pull registry.redhat.io/rhel9/tang
  2. コンテナーを実行し、そのポートを指定して Tang 鍵へのパスを指定します。上記の例では、tang コンテナーを実行し、ポート 7500 を指定し、/var/db/tang ディレクトリーの Tang 鍵へのパスを示します。

    # podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel9/tang

    Tang はデフォルトでポート 80 を使用しますが、Apache HTTP サーバーなどの他のサービスと共存する可能性があることに注意してください。

  3. (必要に応じて) セキュリティーを強化する場合は、Tang 鍵を定期的にローテーションします。tangd-rotate-keys スクリプトを使用できます。以下に例を示します。

    # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel9/tang tangd-rotate-keys -v -d /var/db/tang
    Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
    Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
    Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
    Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
    Keys rotated successfully.

検証

  • Tang サーバーが存在しているために自動アンロック用に LUKS で暗号化したボリュームが含まれているシステムで、Clevis クライアントが Tang を使用してプレーンテキストのメッセージを暗号化および復号化できることを確認します。

    # echo test | clevis encrypt tang '{"url":"http://localhost:7500"}' | clevis decrypt
    The advertisement contains the following signing keys:
    
    x1AIpc6WmnCU-CabD8_4q18vDuw
    
    Do you wish to trust these keys? [ynYN] y
    test

    上記のコマンド例は、localhost URL で Tang サーバーが利用できる場合にその出力の最後に テスト 文字列を示し、ポート 7500 経由で通信します。

関連情報

  • podman(1)clevis(1) および tang(8) の man ページ

11.16. Clevis および Tang のシステムロールの概要

RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した設定インターフェースを提供する Ansible ロールおよびモジュールの集合です。

Clevis および Tang を使用した PBD (Policy-Based Decryption) ソリューションの自動デプロイメント用 Ansible ロールを使用することができます。rhel-system-roles パッケージには、これらのシステムロール、関連する例、リファレンスドキュメントが含まれます。

Network Bound Disk Encryption Client システムロールを使用すると、複数の Clevis クライアントを自動的にデプロイできます。Network Bound Disk Encryption Client ロールは Tang バインディングのみをサポートし、現時点では TPM2 バインディングには使用できないことに注意してください。

Network Bound Disk Encryption Client ロールには、LUKS を使用してすでに暗号化されているボリュームが必要です。このロールは、LUKS 暗号化ボリュームを 1 つまたは複数の NBDE (Network-Bound) サーバー (Tang サーバー) にバインドすることに対応します。既存のボリューム暗号をパスフレーズで保持するか、削除できます。パスフレーズを削除したら、NBDE のみを使用してボリュームのロックを解除できます。これは、システムのプロビジョニング後に削除する必要のある一時的なキーまたはパスワードを使用して、ボリュームが最初に暗号化されている場合に役立ちます。

パスフレーズと鍵ファイルの両方を指定する場合、ロールは最初に指定したものを使用します。有効なバインディングが見つからないと、既存のバインディングからパスフレーズを取得しようとします。

PBD では、デバイスをスロットにマッピングするものとしてバインディングを定義します。つまり、同じデバイスに複数のバインディングを設定できます。デフォルトのスロットは slot 1 です。

Network Bound Disk Encryption Client ロールは、state 変数も提供します。新しいバインディングを作成するか、既存のバインディングを更新する場合は、present を使用します。clevis luks bind とは異なり、state: present を使用してデバイススロットにある既存のバインディングを上書きすることもできます。absent に設定すると、指定したバインディングが削除されます。

Network Bound Disk Encryption Server システムロールを使用すると、自動ディスク暗号化ソリューションの一部として、Tang サーバーをデプロイして管理できます。このロールは以下の機能をサポートします。

  • Tang 鍵のローテーション
  • Tang 鍵のデプロイおよびバックアップ

関連情報

  • NBDE (Network-Bound Disk Encryption) ロール変数の詳細は、rhel-system-roles パッケージをインストールし、/usr/share/doc/rhel-system-roles/nbde_client//usr/share/doc/rhel-system-roles/nbde_server/ ディレクトリーの README.mdREADME.html ファイルを参照してください。
  • たとえば、system-roles Playbook の場合は、rhel-system-roles パッケージをインストールし、/usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ ディレクトリーを参照してください。
  • RHEL システムロールの詳細は、「RHEL システムロールの 概要」を参照してください。

11.17. 複数の Tang サーバーの設定での NBDE Server システムロールの使用

以下の手順に従って、Tangサーバー設定を含む Ansible Playbook を準備および適用します。

前提条件

  • 管理ノード 1 つまたは複数へのアクセスおよびパーミッション。これは、NBDE Server システムロールで設定するシステムです。
  • Ansible Core が他のシステムを設定するシステムである制御ノードへのアクセスと許可。

    コントロールノードに、

    • ansible-core パッケージおよび rhel-system-roles パッケージがインストールされている。
重要

RHEL 8.0-8.5 は、Ansible に基づく自動化用に Ansible Engine 2.9 が含まれる別の Ansible リポジトリーへのアクセスを提供していました。Ansible Engine には、ansibleansible-playbookdockerpodman などのコネクター、多くのプラグインやモジュールなどのコマンドラインユーティリティーが含まれます。Ansible Engine の取得およびインストール方法の詳細は、ナレッジベースの記事「 How to download and install Red Hat Ansible Engine 」を参照してください。

RHEL 8.6 および 9.0 では、Ansible Core が導入されました( ansible-core パッケージとして提供)。これには、Ansible コマンドラインユーティリティー、コマンド、およびビルトイン Ansible プラグインの小規模なセットが含まれます。RHEL は AppStream リポジトリーを介してこのパッケージを提供し、サポート範囲が限定されています。詳細は、ナレッジベース の記事「RHEL 9 および RHEL 8.6 以降の AppStream リポジトリーに含まれる Ansible Core パッケージのサポート範囲」を参照し てください。

  • 管理対象ノードが記載されているインベントリーファイルがある。

手順

  1. Tang サーバーの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml
  2. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

    # vi my-tang-playbook.yml
  3. 必要なパラメーターを追加します。以下の Playbook の例では、Tang サーバーのデプロイとキーローテーションを確実に実行します。

    ---
    - hosts: all
    
      vars:
        nbde_server_rotate_keys: yes
    
      roles:
        - rhel-system-roles.nbde_server
  4. 終了した Playbook を適用します。

    # ansible-playbook -i inventory-file my-tang-playbook.yml

    ここで、* inventory-file はインベントリーファイルです。* logging-playbook.yml は使用する Playbook に置き換えます。

重要

Clevis がインストールされているシステムで grubby ツールを使用して、システム起動時の早い段階で Tang ピンのネットワークを利用できるようにするには、次のコマンドを実行します。

# grubby --update-kernel=ALL --args="rd.neednet=1"

関連情報

  • 詳細は、rhel-system-roles パッケージをインストールして、/usr/share/doc/rhel-system-roles/nbde_server/ ディレクトリーおよび usr/share/ansible/roles/rhel-system-roles.nbde_server/ ディレクトリーを参照してください。

11.18. 複数の Clevis クライアントの設定に NBDE クライアントシステムロールを使用

手順に従って、Clevisクライアント設定を含む Ansible Playbook を準備および適用します。

注記

NBDE クライアントシステムロールは、Tang バインディングのみをサポートします。これは、現時点では TPM2 バインディングに使用できないことを意味します。

前提条件

  • 管理ノード 1 つまたは複数へのアクセスおよびパーミッション。これは、NBDE クライアントシステムロールで設定するシステムです。
  • コントロールノード (このシステムから Red Hat Ansible Core は他のシステムを設定) へのアクセスおよびパーミッション。
  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • rhel-system-roles パッケージが、Playbook を実行するシステムにインストールされている。

手順

  1. Clevis クライアントの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml
  2. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

    # vi my-clevis-playbook.yml
  3. 必要なパラメーターを追加します。以下の Playbook の例では、2 つの Tang サーバーのうち少なくとも 1 台が利用可能な場合に、LUKS で暗号化した 2 つのボリュームを自動的にアンロックするように Clevis クライアントを設定します。

    ---
    - hosts: all
    
      vars:
        nbde_client_bindings:
          - device: /dev/rhel/root
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
          - device: /dev/rhel/swap
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
    
      roles:
        - rhel-system-roles.nbde_client
  4. 終了した Playbook を適用します。

    # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml
重要

Clevis がインストールされているシステムで grubby ツールを使用して、システム起動時の早い段階で Tang ピンのネットワークを利用できるようにするには、次のコマンドを実行します。

# grubby --update-kernel=ALL --args="rd.neednet=1"

関連情報

  • パラメーターの詳細と、NBDE クライアントシステムロールに関する追加情報は、rhel-system-roles パッケージをインストールし、/usr/share/doc/rhel-system-roles/nbde_client/ ディレクトリーおよび /usr/share/ansible/roles/rhel-system-roles.nbde_client/ ディレクトリーを参照してください。

11.19. 関連情報

第12章 システムの監査

Audit は、追加のセキュリティー機能をシステムに提供するのではありません。システムで使用されるセキュリティーポリシーの違反を発見するために使用できます。このような違反は、SELinux などの別のセキュリティー対策で防ぐことができます。

12.1. Linux の Audit

Linux の Audit システムは、システムのセキュリティー関連情報を追跡する方法を提供します。事前設定されたルールに基づき、Audit は、ログエントリーを生成し、システムで発生しているイベントに関する情報をできるだけ多く記録します。この情報は、ミッションクリティカルな環境でセキュリティーポリシーの違反者と、違反者によるアクションを判断する上で必須のものです。

以下は、Audit がログファイルに記録できる情報の概要です。

  • イベントの日時、タイプ、結果
  • サブジェクトとオブジェクトの機密性のラベル
  • イベントを開始したユーザーの ID とイベントの関連性
  • Audit 設定の全修正および Audit ログファイルへのアクセス試行
  • SSH、Kerberos、およびその他の認証メカニズムの全使用
  • 信頼できるデータベース (/etc/passwd など) への変更
  • システムからの情報のインポート、およびシステムへの情報のエクスポートの試行
  • ユーザー ID、サブジェクトおよびオブジェクトラベルなどの属性に基づく include または exclude イベント

Audit システムの使用は、多くのセキュリティー関連の認定における要件でもあります。Audit は、以下の認定またはコンプライアンスガイドの要件に合致するか、それを超えるように設計されています。

  • Controlled Access Protection Profile (CAPP)
  • Labeled Security Protection Profile (LSPP)
  • Rule Set Base Access Control (RSBAC)
  • NISPOM (National Industrial Security Program Operating Manual)
  • Federal Information Security Management Act (FISMA)
  • PCI DSS (Payment Card Industry Data Security Standard)
  • セキュリティー技術実装ガイド (Security Technical Implementation Guide (STIG))

Audit は以下でも認定されています。

  • National Information Assurance Partnership (NIAP) および Best Security Industries (BSI) による評価
  • Red Hat Enterprise Linux 5 における LSPP/CAPP/RSBAC/EAL4 以降の認定
  • Red Hat Enterprise Linux 6 における OSPP/EAL4 以降のオペレーティングシステム保護プロファイル/評価レベル 4 以降(OSPP/EAL4 以降)の認定

使用例

ファイルアクセスの監視
Audit は、ファイルやディレクトリーがアクセス、修正、または実行されたか、もしくはファイル属性が変更されたかを追跡できます。これはたとえば、重要なファイルへのアクセスを検出し、これらのファイルが破損した場合に監査証跡を入手可能とする際に役に立ちます。
システムコールの監視
Audit は、一部のシステムコールが使用されるたびにログエントリーを生成するように設定できます。これを使用すると、settimeofdayclock_adjtime、その他の時間関連のシステムコールを監視することで、システム時間への変更を追跡できます。
ユーザーが実行したコマンドの記録
Audit はファイルが実行されたかどうかを追跡できるため、特定のコマンドの実行を毎回記録するようにルールを定義できます。たとえば、/bin ディレクトリー内のすべての実行可能ファイルにルールを定義できます。これにより作成されるログエントリーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成できます。
システムのパス名の実行の記録
ルールの呼び出し時にパスを inode に変換するファイルアクセスをウォッチする以外に、ルールの呼び出し時に存在しない場合や、ルールの呼び出し後にファイルが置き換えられた場合でも、Audit がパスの実行をウォッチできるようになりました。これにより、ルールは、プログラム実行ファイルをアップグレードした後、またはインストールされる前にも機能を継続できます。
セキュリティーイベントの記録
pam_faillock 認証モジュールは、失敗したログイン試行を記録できます。Audit で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーに関する追加情報が提供されます。
イベントの検索
Audit は ausearch ユーティリティーを提供します。これを使用すると、ログエントリーをフィルターにかけ、いくつかの条件に基づく完全な監査証跡を提供できます。
サマリーレポートの実行
aureport ユーティリティーを使用すると、記録されたイベントのデイリーレポートを生成できます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに調べることができます。
ネットワークアクセスの監視
nftablesiptables、および ebtables ユーティリティーは、Audit イベントを発生するように設定できるため、システム管理者がネットワークアクセスを監視できるようになります。
注記

システムのパフォーマンスは、Audit が収集する情報量によって影響される可能性があります。

12.2. Audit システムのアーキテクチャー

Audit システムは、ユーザー空間アプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要部分で構成されます。カーネルコンポーネントは、ユーザー空間アプリケーションからシステムコールを受け、これを usertaskfstype、または exit のいずれかのフィルターで振り分けます。

システムコールが exclude フィルターを通過すると、前述のフィルターのいずれかに送られます。このフィルターにより、Audit ルール設定に基づいてシステムコールが Audit デーモンに送信され、さらに処理されます。

ユーザー空間の Audit デーモンは、カーネルから情報を収集し、ログファイルのエントリーを作成します。他のユーザー空間ユーティリティーは、Audit デーモン、カーネルの Audit コンポーネント、または Audit ログファイルと相互作用します。

  • auditctl - Audit 制御ユーティリティーはカーネル Audit コンポーネントと相互作用し、ルールを管理するだけでなくイベント生成プロセスの多くの設定やパラメーターも制御します。
  • 残りの Audit ユーティリティーは、Audit ログファイルのコンテンツを入力として受け取り、ユーザーの要件に基づいて出力を生成します。たとえば、aureport ユーティリティーは、記録された全イベントのレポートを生成します。

RHEL 9 では、Audit dispatcher デーモン (audisp) 機能は、Audit デーモン (auditd) に統合されています。監査イベントと、リアルタイムの分析プログラムの相互作用に使用されるプラグイン設定ファイルは、デフォルトで /etc/audit/plugins.d/ ディレクトリーに保存されます。

12.3. 環境を保護するための auditd の設定

デフォルトの auditd 設定は、ほとんどの環境に適しています。ただし、厳格なセキュリティーポリシーに対応する必要がある場合は、/etc/audit/auditd.conf ファイルの Audit デーモン設定に以下の設定が推奨されます。

log_file
Audit ログファイル (通常は /var/log/audit/) を保持するディレクトリーは、別のマウントポイントにマウントされている必要があります。これにより、その他のプロセスがこのディレクトリー内の領域を使用しないようにし、Audit デーモンの残りの領域を正確に検出します。
max_log_file
1 つの Audit ログファイルの最大サイズを指定します。Audit ログファイルを保持するパーティションで利用可能な領域をすべて使用するように設定する必要があります。
max_log_file_action
max_log_file に設定した制限に達したときに実行するアクションを決定します。Audit ログファイルが上書きされないように keep_logs に設定する必要があります。
space_left
space_left_action パラメーターで設定されたアクションがトリガーされるディスクに残っている空き領域の量を指定します。管理者は、ディスクの領域を反映して解放するのに十分な時間を設定する必要があります。space_left の値は、Audit ログファイルが生成されるレートによって異なります。
space_left_action
適切な通知方法を使用して、space_left_action パラメーターを email または exec に設定することをお勧めします。
admin_space_left
admin_space_left_action パラメーターで設定されたアクションがトリガーされる空きスペースの絶対最小量を指定します。これは、管理者によって実行されたアクションをログに記録するのに十分なスペースを残す値に設定する必要があります。
admin_space_left_action
single を、システムをシングルユーザーモードにし、管理者がディスク領域を解放できるようにします。
disk_full_action
Audit ログファイルが含まれるパーティションに空き領域がない場合に発生するアクションを指定します (halt または single に設定する必要があります)。これにより、Audit がイベントをログに記録できなくなると、システムは、シングルユーザーモードでシャットダウンまたは動作します。
disk_error_action
Audit ログファイルが含まれるパーティションでエラーが検出された場合に発生するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカルのセキュリティーポリシーに基づいて、syslogsinglehalt のいずれかに設定する必要があります。
flush
incremental_async に設定する必要があります。これは freq パラメーターと組み合わせて機能します。これは、ハードドライブとのハード同期を強制する前にディスクに送信できるレコードの数を指定します。freq パラメーターは 100 に設定する必要があります。このパラメーターにより、アクティビティーが集中した際に高いパフォーマンスを保ちつつ、Audit イベントデータがディスクのログファイルと確実に同期されるようになります。

残りの設定オプションは、ローカルのセキュリティーポリシーに合わせて設定します。

12.4. auditd の開始および制御

auditd が設定されたら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。root ユーザーで次のコマンドを実行し、auditd を起動します。

service auditd start

システムの起動時に auditd が開始するように設定するには、次のコマンドを実行します。

systemctl enable auditd

# auditctl -e 0auditd を一時的に無効にし、# auditctl -e 1 で再度有効にできます。

service auditd action コマンドを使用すると、auditd でさまざまなアクションを実行できます。ここでの アクション は以下のいずれかになります。

stop
auditd を停止します。
restart
auditd を再起動します。
reload または force-reload
/etc/audit/auditd.conf ファイルから auditd の設定を再ロードします。
rotate
/var/log/audit/ ディレクトリーのログファイルをローテーションします。
resume
Audit イベントのログが一旦停止した後、再開します。たとえば、Audit ログファイルが含まれるディスクパーティションの未使用領域が不足している場合などです。
condrestart または try-restart
auditd がすでに起動している場合にのみ、これを再起動します。
status
auditd の稼働状況を表示します。
注記

service コマンドは、auditd デーモンと正しく相互作用する唯一の方法です。auid 値が適切に記録されるように、service コマンドを使用する必要があります。systemctl コマンドは、2 つのアクション (enable および status) にのみ使用できます。

12.5. Audit ログファイルについて

デフォルトでは、Audit システムはログエントリーを /var/log/audit/audit.log ファイルに保存します。ログローテーションが有効になっていれば、ローテーションされた audit.log ファイルは同じディレクトリーに保存されます。

下記の Audit ルールを追加して、/etc/ssh/sshd_config ファイルの読み取りまたは修正の試行をすべてログに記録します。

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config

auditd デーモンが実行している場合は、たとえば次のコマンドを使用して、Audit ログファイルに新しいイベントを作成します。

cat /etc/ssh/sshd_config

このイベントは、audit.log ファイルでは以下のようになります。

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967

上記のイベントは 4 つのレコードで構成されており、タイムスタンプとシリアル番号を共有します。レコードは、常に type= で始まります。各レコードには、スペースまたはコンマで区切られた名前と値のペア (name=value) が複数使用されています。上記のイベントの詳細な分析は以下のようになります。

1 つ目のレコード

type=SYSCALL
type フィールドには、レコードのタイプが記載されます。この例の SYSCALL 値は、カーネルへのシステムコールによりこれが記録されたことを示しています。
msg=audit(1364481363.243:24287):

msg フィールドには以下が記録されます。

  • audit(time_stamp:ID) 形式のレコードのタイムスタンプおよび一意の ID。複数のレコードが同じ Audit イベントの一部として生成されている場合は、同じタイムスタンプおよび ID を共有できます。タイムスタンプは Unix の時間形式です (1970 年 1 月 1 日 00:00:00 UTC からの秒数)。
  • カーネル空間およびユーザー空間のアプリケーションが提供するさまざまなイベント固有の name=value ペア。
arch=c000003e
arch フィールドには、システムの CPU アーキテクチャーに関する情報が含まれます。c000003e の値は 16 進数表記で記録されます。ausearch コマンドで Audit レコードを検索する場合は、-i オプションまたは --interpret オプションを使用して、16 進数の値を人間が判読できる値に自動的に変換します。c000003e 値は x86_64 として解釈されます。
syscall=2
syscall フィールドは、カーネルに送信されたシステムコールのタイプを記録します。値が 2 の場合は、/usr/include/asm/unistd_64.h ファイルに、人間が判読できる値を指定できます。この場合の 2 は、オープン なシステムコールです。ausyscall ユーティリティーでは、システムコール番号を、人間が判読できる値に変換できます。ausyscall --dump コマンドを使用して、システムコールの一覧とその数字を表示します。詳細は、ausyscall(8) の man ページを参照してください。
success=no
success フィールドは、その特定のイベントで記録されたシステムコールが成功したかどうかを記録します。この例では、呼び出しが成功しませんでした。
exit=-13

exit フィールドには、システムコールが返した終了コードを指定する値が含まれます。この値は、システムコールにより異なります。次のコマンドを実行すると、この値を人間が判読可能なものに変換できます。

ausearch --interpret --exit -13

この例では、監査ログに、終了コード -13 で失敗したイベントが含まれていることが前提となります。

a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a
a0 から a3 までのフィールドは、このイベントにおけるシステムコールの最初の 4 つの引数を、16 進法で記録します。この引数は、使用されるシステムコールにより異なります。ausearch ユーティリティーで解釈できます。
items=1
items フィールドには、システムコールのレコードに続く PATH 補助レコードの数が含まれます。
ppid=2686
ppid フィールドは、親プロセス ID (PPID) を記録します。この例では、2686 は、bash などの親プロセスの PPID です。
pid=3538
pid フィールドは、プロセス ID (PID) を記録します。この例の 3538cat プロセスの PID です。
auid=1000
auid フィールドには、loginuid である Audit ユーザー ID が記録されます。この ID は、ログイン時にユーザーに割り当てられ、ユーザーの ID が変更した後でもすべてのプロセスに引き継がれます (たとえば、su - john コマンドでユーザーアカウントを切り替えた場合)。
uid=1000
uid フィールドは、解析しているプロセスを開始したユーザーのユーザー ID を記録します。ユーザー ID は、ausearch -i --uid UID のコマンドを使用するとユーザー名に変換されます。
gid=1000
gid フィールドは、解析しているプロセスを開始したユーザーのグループ ID を記録します。
euid=1000
euid フィールドは、解析しているプロセスを開始したユーザーの実効ユーザー ID を記録します。
suid=1000
suid フィールドは、解析しているプロセスを開始したユーザーのセットユーザー ID を記録します。
fsuid=1000
fsuid フィールドは、解析しているプロセスを開始したユーザーのファイルシステムユーザー ID を記録します。
egid=1000
egid フィールドは、解析しているプロセスを開始したユーザーの実効グループ ID を記録します。
sgid=1000
sgid フィールドは、解析しているプロセスを開始したユーザーのセットグループ ID を記録します。
fsgid=1000
fsgid フィールドは、解析しているプロセスを開始したユーザーのファイルシステムグループ ID を記録します。
tty=pts0
tty フィールドは、解析しているプロセスが開始したターミナルを記録します。
ses=1
ses フィールドは、解析しているプロセスが開始したセッションのセッション ID を記録します。
comm="cat"
comm フィールドは、解析しているプロセスを開始するために使用したコマンドのコマンドライン名を記録します。この例では、この Audit イベントを発生するのに、cat コマンドが使用されました。
exe="/bin/cat"
exe フィールドは、解析しているプロセスを開始するために使用した実行可能ファイルへのパスを記録します。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj フィールドは、解析しているプロセスの実行時にラベル付けされた SELinux コンテンツを記録します。
key="sshd_config"
key フィールドは、Audit ログでこのイベントを生成したルールに関連付けられている管理者による定義の文字列を記録します。

2 つ目のレコード

type=CWD

2 つ目のレコードの type フィールドの値は、CWD (現在の作業ディレクトリー) です。このタイプは、最初のレコードで指定されたシステムコールを開始したプロセスの作業ディレクトリーを記録するために使用されます。

この記録の目的は、相対パスが関連する PATH 記録に保存された場合に、現行プロセスの位置を記録することにあります。これにより、絶対パスを再構築できます。

msg=audit(1364481363.243:24287)
msg フィールドは、最初のレコードと同じタイムスタンプと ID の値を保持します。タイムスタンプは Unix の時間形式です (1970 年 1 月 1 日 00:00:00 UTC からの秒数)。
cwd="/home/user_name"
cwd フィールドは、システムコールが開始したディレクトリーのパスになります。

3 つ目のレコード

type=PATH
3 つ目のレコードでは、type フィールドの値は PATH です。Audit イベントには、システムコールに引数として渡されたすべてのパスに PATH タイプのレコードが含まれます。この Audit イベントでは、1 つのパス (/etc/ssh/sshd_config) のみが引数として使用されます。
msg=audit(1364481363.243:24287):
msg フィールドは、1 つ目と 2 つ目のレコードと同じタイムスタンプと ID になります。
item=0
item フィールドは、SYSCALL タイプレコードで参照されているアイテムの合計数のうち、現在のレコードがどのアイテムであるかを示します。この数はゼロベースで、0 は最初の項目であることを示します。
name="/etc/ssh/sshd_config"
name フィールドは、システムコールに引数として渡されたファイルまたはディレクトリーのパスを記録します。この場合、これは /etc/ssh/sshd_config ファイルです。
inode=409248

inode フィールドには、このイベントで記録されたファイルまたはディレクトリーに関連する inode 番号が含まれます。以下のコマンドは、inode 番号 409248 に関連するファイルまたはディレクトリーを表示します。

find / -inum 409248 -print
/etc/ssh/sshd_config
dev=fd:00
dev フィールドは、このイベントで記録されたファイルまたはディレクトリーを含むデバイスのマイナーおよびメジャーの ID を指定します。ここでは、値が /dev/fd/0 デバイスを示しています。
mode=0100600
mode フィールドは、ファイルまたはディレクトリーのパーミッションを、st_mode フィールドの stat コマンドが返す数字表記で記録します。詳細は、stat(2) の man ページを参照してください。この場合、0100600-rw------- として解釈されます。つまり、root ユーザーにのみ、/etc/ssh/sshd_config ファイルに読み取りおよび書き込みのパーミッションが付与されます。
ouid=0
ouid フィールドは、オブジェクトの所有者のユーザー ID を記録します。
ogid=0
ogid フィールドは、オブジェクトの所有者のグループ ID を記録します。
rdev=00:00
rdev フィールドには、特定ファイルにのみ記録されたデバイス識別子が含まれます。ここでは、記録されたファイルは通常のファイルであるため、このフィールドは使用されません。
obj=system_u:object_r:etc_t:s0
obj フィールドは、実行時に、記録されているファイルまたはディレクトリーにラベル付けする SELinux コンテキストを記録します。
nametype=NORMAL
nametype フィールドは、指定したシステムコールのコンテキストで各パスのレコード操作の目的を記録します。
cap_fp=none
cap_fp フィールドは、ファイルまたはディレクトリーオブジェクトで許可されたファイルシステムベースの機能の設定に関連するデータを記録します。
cap_fi=none
cap_fi フィールドは、ファイルまたはディレクトリーオブジェクトの継承されたファイルシステムベースの機能の設定に関するデータを記録します。
cap_fe=0
cap_fe フィールドは、ファイルまたはディレクトリーオブジェクトのファイルシステムベースの機能の有効ビットの設定を記録します。
cap_fver=0
cap_fver フィールドは、ファイルまたはディレクトリーオブジェクトのファイルシステムベースの機能のバージョンを記録します。

4 つ目のレコード

type=PROCTITLE
type フィールドには、レコードのタイプが記載されます。この例の PROCTITLE 値は、このレコードにより、カーネルへのシステムコールにより発生するこの監査イベントを発生させた完全なコマンドラインを提供することが指定されることを示しています。
proctitle=636174002F6574632F7373682F737368645F636F6E666967
proctitle フィールドは、解析しているプロセスを開始するために使用したコマンドのコマンドラインを記録します。このフィールドは 16 進数の表記で記録され、Audit ログパーサーに影響が及ばないようにします。このテキストは、この Audit イベントを開始したコマンドに復号します。ausearch コマンドで Audit レコードを検索する場合は、-i オプションまたは --interpret オプションを使用して、16 進数の値を人間が判読できる値に自動的に変換します。636174002F6574632F7373682F737368645F636F6E666967 値は、cat /etc/ssh/sshd_config として解釈されます。

12.6. auditctl で Audit ルールを定義および実行

Audit システムは、ログファイルで取得するものを定義する一連のルールで動作します。Audit ルールは、auditctl ユーティリティーを使用してコマンドラインで設定するか、/etc/audit/rules.d/ ディレクトリーで設定できます。

auditctl コマンドを使用すると、Audit システムの基本的な機能を制御し、どの Audit イベントをログに記録するかを指定するルールを定義できます。

ファイルシステムのルールの例

  1. すべての書き込みアクセスと /etc/passwd ファイルのすべての属性変更をログに記録するルールを定義するには、次のコマンドを実行します。

    # auditctl -w /etc/passwd -p wa -k passwd_changes
  2. すべての書き込みアクセスと、/etc/selinux/ ディレクトリー内の全ファイルへのアクセスと、その属性変更をすべてログに記録するルールを定義するには、次のコマンドを実行します。

    # auditctl -w /etc/selinux/ -p wa -k selinux_changes

システムロールのルールの例

  1. システムで 64 ビットアーキテクチャーが使用され、システムコールの adjtimex または settimeofday がプログラムにより使用されるたびにログエントリーを作成するルールを定義するには、次のコマンドを実行します。

    # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
  2. ユーザー ID が 1000 以上のシステムユーザーがファイルを削除したりファイル名を変更するたびに、ログエントリーを作成するルールを定義するには、次のコマンドを実行します。

    # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

    -F auid!=4294967295 オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。

実行可能なファイルルール

/bin/id プログラムのすべての実行をログに取得するルールを定義するには、次のコマンドを実行します。

# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id

関連情報

  • man ページの auditctl(8)

12.7. 永続的な Audit ルールの定義

再起動後も持続するように Audit ルールを定義するには、/etc/audit/rules.d/audit.rules ファイルに直接追加するか、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込む augenrules プログラムを使用する必要があります。

auditd サービスを開始すると、/etc/audit/audit.rules ファイルが生成されることに注意してください。/etc/audit/rules.d/ のファイルは、同じ auditctl コマンドライン構文を使用してルールを指定します。ハッシュ記号 (#) に続く空の行とテキストは無視されます。

また、auditctl コマンドは、以下のように -R オプションを使用して指定したファイルからルールを読み込むのに使用することもできます。

# auditctl -R /usr/share/audit/sample-rules/30-stig.rules

12.8. 事前に設定されたルールファイルの使用

/usr/share/audit/sample-rules ディレクトリーには、audit パッケージが各種の証明書規格に従って、事前設定ルールのファイル一式が提供されています。

30-nispom.rules
NISPOM (National Industrial Security Program Operating Manual) の「Information System Security」の章で指定している要件を満たす Audit ルール設定
30-ospp-v42*.rules
OSPP (Protection Profile for General Purpose Operating Systems) プロファイルバージョン 4.2 に定義されている要件を満たす監査ルール設定
30-pci-dss-v31.rules
PCI DSS (Payment Card Industry Data Security Standard) v3.1 に設定されている要件を満たす監査ルール設定
30-stig.rules
セキュリティー技術実装ガイド (STIG: Security Technical Implementation Guide) で設定されている要件を満たす Audit ルール設定

上記の設定ファイルを使用するには、/etc/audit/rules.d/ ディレクトリーにコピーして、以下のように augenrules --load コマンドを使用します。

# cd /usr/share/audit/sample-rules/
# cp 10-base-config.rules 30-stig.rules 31-privileged.rules 99-finalize.rules /etc/audit/rules.d/
# augenrules --load

番号指定スキームを使用して監査ルールを順序付けできます。詳細は、/usr/share/audit/sample-rules/README-rules ファイルを参照してください。

関連情報

  • audit.rules(7) man ページ

12.9. 永続ルールを定義する augenrules の使用

augenrules スクリプトは、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込み、audit.rules ファイルにコンパイルします。このスクリプトは、自然なソート順序の特定の順番で、.rules で終わるすべてのファイルを処理します。このディレクトリーのファイルは、以下の意味を持つグループに分類されます。

  • 10 - カーネルおよび auditctl の設定
  • 20 - 一般的なルールに該当してしまう可能性もあるが、ユーザー側で独自ルールを作成することも可能
  • 30 - 主なルール
  • 40 - 任意のルール
  • 50 - サーバー固有のルール
  • 70 - システムのローカルルール
  • 90 - ファイナライズ (不変)

ルールは、すべてを一度に使用することは意図されていません。ルールは考慮すべきポリシーの一部であり、個々のファイルは /etc/audit/rules.d/ にコピーされます。たとえば、STIG 設定でシステムを設定し、10-base-config30-stig31-privileged99-finalize の各ルールをコピーします。

/etc/audit/rules.d/ ディレクトリーにルールを置いたら、--load ディレクティブで augenrules スクリプトを実行することでそれを読み込みます。

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
...

関連情報

  • audit.rules(8) および augenrules(8) の man ページ

12.10. augenrules の無効化

augenrules ユーティリティーを無効にするには、以下の手順に従います。これにより、Audit が /etc/audit/audit.rules ファイルで定義されたルールを使用するように切り替えます。

手順

  1. /usr/lib/systemd/system/auditd.service ファイルを /etc/systemd/system/ ディレクトリーにコピーします。

    # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/
  2. 任意のテキストエディターで /etc/systemd/system/auditd.service ファイルを編集します。以下に例を示します。

    # vi /etc/systemd/system/auditd.service
  3. augenrules を含む行をコメントアウトし、auditctl -R コマンドを含む行のコメント設定を解除します。

    #ExecStartPost=-/sbin/augenrules --load
    ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
  4. systemd デーモンを再読み込みして、auditd.service ファイルの変更を取得します。

    # systemctl daemon-reload
  5. auditd サービスを再起動します。

    # service auditd restart

関連情報

12.11. ソフトウェアの更新を監視するためのAuditの設定

事前設定されたルール44-installers.rulesを使用して、ソフトウェアをインストールする次のユーティリティを監視するようにAuditを設定できます。

  • dnf [2]
  • yum
  • pip
  • npm
  • cpan
  • gem
  • luarocks

rpmユーティリティを監視するには、 rpm-plugin-auditパッケージをインストールします。その後、Auditは、パッケージをインストールまたは更新するときにSOFTWARE_UPDATEイベントを生成します。これらのイベントを一覧表示するには、コマンドラインでausearch -m SOFTWARE_UPDATEと入力します。

注記

事前設定されたルールファイルは、ppc64leおよびaarch64アーキテクチャを備えたシステムでは使用できません。

前提条件

手順

  1. 事前設定されたルールファイル44-installers.rules/usr/share/audit/sample-rules/ディレクトリから/etc/audit/rules.d/ディレクトリにコピーします。

    # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/
  2. 監査ルールを読み込みます。

    # augenrules --load

検証

  1. 読み込まれたルールを一覧表示します。

    # auditctl -l
    -p x-w /usr/bin/dnf-3 -k software-installer
    -p x-w /usr/bin/yum -k software-installer
    -p x-w /usr/bin/pip -k software-installer
    -p x-w /usr/bin/npm -k software-installer
    -p x-w /usr/bin/cpan -k software-installer
    -p x-w /usr/bin/gem -k software-installer
    -p x-w /usr/bin/luarocks -k software-installer
  2. インストールを実行します。以下に例を示します

    # dnf reinstall -y vim-enhanced
  3. Auditログで最近のインストールイベントを検索します。次に例を示します。

    # ausearch -ts recent -k software-installer
    ––––
    time->Thu Dec 16 10:33:46 2021
    type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
    type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(1639668826.074:298): cwd="/root"
    type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
    type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"


[2] dnfはRHELではシンボリックリンクであるため、dnf Auditルールのパスにはシンボリックリンクのターゲットが含まれている必要があります。正しいAuditイベントを受信するには、path=/usr/bin/dnfパスを/usr/bin/dnf-3に変更して、44-installers.rulesファイルを変更します。

12.12. Auditによるユーザーログイン時刻の監視

特定の時刻にログインしたユーザーを監視するために、特別な方法でAuditを設定する必要はありません。同じ情報を表示する異なる方法を提供するausearchまたはaureportツールを使用できます。

前提条件

手順

ユーザーのログイン時刻を表示するには、次のいずれかのコマンドを使用します。

  • 監査ログでUSER_LOGINメッセージタイプを検索します。

    # ausearch -m USER_LOGIN -ts '12/02/2020' '18:00:00' -sv no
    time->Mon Nov 22 07:33:22 2021
    type=USER_LOGIN msg=audit(1637584402.416:92): pid=1939 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=10.37.128.108 terminal=ssh res=failed'
    • -tsオプションを使用して日付と時刻を指定できます。このオプションを使用しない場合、 ausearchは今日の結果を提供し、時刻を省略すると、 ausearchは午前0時からの結果を提供します。
    • 成功したログイン試行を除外するには-sv yesオプションを、失敗したログイン試行を除外するには-sv noを、それぞれ使用することができます。
  • ausearchコマンドの生の出力をaulastユーティリティにパイプで渡します。このユーティリティは、lastコマンドの出力と同様の形式で出力を表示します。以下に例を示します。

    # ausearch --raw | aulast --stdin
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.22.16.106     Mon Nov 22 07:40 - 07:40  (00:00)
    reboot   system boot  4.18.0-348.6.el8 Mon Nov 22 07:33
  • --login -iオプションを指定してaureportコマンドを使用し、ログインイベントのリストを表示します。

    # aureport --login -i
    
    Login Report
    ============================================
    # date time auid host term exe success event
    ============================================
    1. 11/16/2021 13:11:30 root 10.40.192.190 ssh /usr/sbin/sshd yes 6920
    2. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6925
    3. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6930
    4. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6935
    5. 11/16/2021 13:11:33 root 10.40.192.190 ssh /usr/sbin/sshd yes 6940
    6. 11/16/2021 13:11:33 root 10.40.192.190 /dev/pts/0 /usr/sbin/sshd yes 6945

関連情報

  • ausearch(8) の man ページ。
  • aulast(8) の man ページ。
  • aureport(8) の man ページ。

第13章 fapolicyd を使用したアプリケーションの拒否および許可

ルールセットに基づいてアプリケーションの実行を許可または拒否するポリシーを設定して有効にすることで、効率的に悪意のある一般的に知られていないソフトウェアや、害を及ぼす可能性のあるソフトウェアの実行を回避できます。

13.1. fapolicyd の概要

fapolicyd ソフトウェアフレームワークは、ユーザー定義のポリシーに基づいてアプリケーションの実行を制御します。このフレームワークは、最適な方法で、システム上で信頼されていないアプリケーションや悪意のあるアプリケーションを実行されないようにします。

fapolicyd フレームワークは、以下のコンテンツを提供します。

  • fapolicyd サービス
  • fapolicyd コマンドラインユーティリティー
  • fapolicyd RPM プラグイン
  • fapolicyd ルール言語
  • fagenrules スクリプト

管理者は、パス、ハッシュ、MIME タイプ、信頼に基づいて、すべてのアプリケーションに実行ルール allow および deny の両方を監査する定義できます。

fapolicyd フレームワークにより、信頼の概念が導入されます。アプリケーションは、システムパッケージマネージャーによって適切にインストールされると信頼されるため、システムの RPM データベースに登録されます。fapolicyd デーモンは、RPM データベースを信頼できるバイナリーとスクリプトの一覧として使用します。fapolicyd RPM プラグインは、DNF Package Manager または RPM Package Manager のいずれかで処理されるシステム更新をすべて登録するようになりました。プラグインは、このデータベースの変更を fapolicyd デーモンに通知します。アプリケーションを追加する他の方法では、カスタムルールを作成し、fapolicyd サービスを再起動する必要があります。

fapolicyd サービス構成は、次の構造を持つ /etc/fapolicyd/ ディレクトリーにあります。

  • /etc/fapolicyd/fapolicyd.trust ファイルには、信頼されるファイルの一覧が含まれます。/etc/fapolicyd/trust.d/ ディレクトリーで複数の信頼ファイルを使用することもできます。
  • allow および deny 実行ルールが含まれるファイルの /etc/fapolicyd/rules.d/ ディレクトリー。fagenrules スクリプトは、これらのコンポーネントルールファイルを /etc/fapolicyd/compiled.rules ファイルにマージします。
  • fapolicyd.conf ファイルには、デーモンの設定オプションが含まれます。このファイルは、主にパフォーマンス調整の目的で役に立ちます。

/etc/fapolicyd/rules.d/ のルールは、それぞれ異なるポリシーゴールを表す複数のファイルで整理されます。対応するファイル名の先頭にある数字は、/etc/fapolicyd/compiled.rules の順序を決定します。

  • 10 - 言語ルール
  • 20: dracut 関連のルール
  • 21 - アップデーターのルール
  • 30 - パターン
  • 40 - ELF ルール
  • 41 - 共有オブジェクトルール
  • 42 - 信頼できる ELF ルール
  • 70 - 信頼された言語ルール
  • 72 - シェルルール
  • 90 - ルールの実行を拒否します
  • 95 - オープンルールを許可します。

fapolicyd 整合性チェックには、以下のいずれかの方法を使用できます。

  • file-size チェック
  • SHA-256 ハッシュの比較
  • Integrity Measurement Architecture (IMA) サブシステム

デフォルトでは、fapolicyd は整合性チェックを行いません。ファイルサイズに基づいた整合性チェックは高速ですが、攻撃者はファイルの内容を置き換え、そのバイトサイズを保持することができます。SHA-256 チェックサムの計算とチェックがより安全ですが、システムのパフォーマンスに影響します。fapolicyd.confintegrity = ima オプションには、実行可能ファイルを含むすべてのファイルシステムでファイル拡張属性 (xattrとしても知られている) のサポートが必要です。

関連情報

  • fapolicyd(8 )、fapolicyd.rules(5 )、fapolicyd.conf(5 )、fapolicyd.trust(13)、および fagenrules(8 )、および fapolicyd-cli(1) の man ページ
  • Managing, monitoring, and updating the kernel』の「Enhancing security with the kernel integrity subsystem」の章を参照してください。
  • fapolicyd パッケージでインストールされるドキュメントは、/usr/share/doc/fapolicyd/ ディレクトリーおよび /usr/share/fapolicyd/sample-rules/README-rules ファイルにあります。

13.2. fapolicyd のデプロイ

RHEL に fapolicyd フレームワークをデプロイするには、以下を行います。

手順

  1. fapolicyd パッケージをインストールします。

    # dnf install fapolicyd
  2. fapolicyd サービスを有効にして開始します。

    # systemctl enable --now fapolicyd

検証

  1. fapolicydサービスが正しく実行されていることを確認します。

    # systemctl status fapolicyd
    ● fapolicyd.service - File Access Policy Daemon
       Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; vendor p>
       Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
      Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
     Main PID: 8819 (fapolicyd)
        Tasks: 4 (limit: 11500)
       Memory: 78.2M
       CGroup: /system.slice/fapolicyd.service
               └─8819 /usr/sbin/fapolicyd
    
    Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
    Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
    Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
    Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
    Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database
  2. root 権限のないユーザーとしてログインし、以下のように fapolicyd が機能していることを確認します。

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted

13.3. 信頼ソースを使用して、ファイルを信頼できるとマークします。

fapolicydフレームワークは、RPMデータベースに含まれるファイルを信頼します。追加のファイルを信頼済みとしてマークするには、対応するエントリーを /etc/fapolicyd/fapolicyd.trust plain-text ファイルまたは /etc/fapolicyd/trust.d/ ディレクトリーに追加します。これは、信頼されたファイルの一覧をさらにファイルに区切ります。テキストエディターまたは fapolicyd-cli コマンドを使用して、fapolicyd.trust または /etc/fapolicyd/trust.d のファイルを直接変更できます。

注記

カスタム fapolicyd ルールを書き込む代わりに、fapolicyd.trust または trust.d/ を使用してファイルを信頼できるとマークすることが推奨されます。

前提条件

  • fapolicyd フレームワークがシステムにデプロイされます。

手順

  1. カスタムバイナリーを必要なディレクトリにコピーします。以下に例を示します。

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  2. カスタムバイナリーを信頼済みとしてマークし、対応するエントリーを myapp ファイルに /etc/fapolicyd/trust.d/ に保存します。

    # fapolicyd-cli --file add /tmp/ls --trust-file myapp

    --trust-file オプションを省略すると、直前のコマンドは対応する行を /etc/fapolicyd/fapolicyd.trust に追加します。

  3. fapolicydデータベースを更新します。

    # fapolicyd-cli --update
  4. fapolicyd を再起動します。

    # systemctl restart fapolicyd

検証

  1. たとえば、カスタムバイナリーが実行できることを確認します。

    $ /tmp/ls
    ls

関連情報

  • fapolicyd.trust(13) man page.

13.4. fapolicyd のカスタムの許可および拒否ルールの追加

fapolicyd パッケージのデフォルトのルールセットは、システム機能に影響しません。バイナリーおよびスクリプトを標準以外のディレクトリーに保存する、または dnf インストーラーまたは rpm インストーラーなしでアプリケーションを追加する場合は、追加のファイルを信頼済みとしてマークするか、新しいカスタムルールを追加する必要があります。

基本的なシナリオでは、信頼 のソースを使用してファイルを信頼済みとしてマークすることが推奨さ れます。特定のユーザーおよびグループ識別子に対してのみカスタムバイナリーを実行できるようにするなどの高度なシナリオでは、/etc/fapolicyd/rules.d/ ディレクトリーに新しいカスタムルールを追加します。

次の手順は、新しいルールを追加してカスタムバイナリーを許可する方法を示しています。

前提条件

  • fapolicyd フレームワークがシステムにデプロイされます。

手順

  1. カスタムバイナリーを必要なディレクトリにコピーします。以下に例を示します。

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  2. fapolicyd サービスを停止します。

    # systemctl stop fapolicyd
  3. デバッグモードを使用して、対応するルールを識別します。fapolicyd --debug コマンドの出力は冗長であり、Ctrl+C を押すか、対応するプロセスを強制終了するだけで停止できるため、エラー出力をファイルにリダイレクトします。この場合は、--debug ではなく --debug-deny オプションを使用して、出力が拒否にのみ制限できます。

    # fapolicyd --debug-deny 2> fapolicy.output &
    [1] 51341

    または、別の端末で fapolicyd デバッグモードを実行できます。

  4. fapolicyd が拒否したコマンドを繰り返します。

    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  5. デバッグモードをフォアグラウンドで再開し、Ctrl+C を押して停止します。

    # fg
    fapolicyd --debug 2> fapolicy.output
    ^C
    ...

    または、fapolicyd デバッグモードのプロセスを強制終了します。

    # kill 51341
  6. アプリケーションの実行を拒否するルールを見つけます。

    # cat fapolicy.output | grep 'deny_audit'
    ...
    rule=13 dec=deny_audit perm=execute auid=0 pid=6855 exe=/usr/bin/bash : path=/tmp/ls ftype=application/x-executable trust=0
  7. カスタムバイナリーの実行を妨げたルールを含むファイルを見つけます。この場合、deny_audit perm=execute ルールは 90-deny-execute.rules ファイルに属します。

    # ls /etc/fapolicyd/rules.d/
    10-languages.rules  40-bad-elf.rules	   72-shell.rules
    20-dracut.rules     41-shared-obj.rules    90-deny-execute.rules
    21-updaters.rules   42-trusted-elf.rules   95-allow-open.rules
    30-patterns.rules   70-trusted-lang.rules
    
    
    # cat /etc/fapolicyd/rules.d/90-deny-execute.rules
    # Deny execution for anything untrusted
    
    deny_audit perm=execute all : all
  8. 新しい allow ルールを、/etc/fapolicyd / rules.d/ ディレクトリーのカスタムバイナリーの実行を拒否したルールが含まれるルールファイルに追加します。

    # touch /etc/fapolicyd/rules.d/80-myapps.rules
    # vi /etc/fapolicyd/rules.d/80-myapps.rules

    以下のルールを 80-myapps.rules ファイルに挿入します。

    allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

    または、/etc/fapolicyd/rules.d/ のルールファイルに次のルールを追加して、/tmp ディレクトリー内のすべてのバイナリーの実行を許可できます。

    allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ all trust=0
  9. カスタムバイナリーのコンテンツの変更を防ぐには、SHA-256 チェックサムを使用して必要なルールを定義します。

    $ sha256sum /tmp/ls
    780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

    ルールを以下の定義に変更します。

    allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836
  10. コンパイルした一覧は /etc/fapolicyd/rules.d/ のルールセットと異なることを確認し、リストを更新します。これは、/etc/fapolicyd/compiled.rules ファイルに保存されます。

    # fagenrules --check
    /usr/sbin/fagenrules: Rules have changed and should be updated
    # fagenrules --load
  11. カスタムルールが fapolicyd ルールの一覧に含まれていることを確認してから、実行を妨げるルールを確認します。

    # fapolicyd-cli --list
    ...
    13. allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0
    14. deny_audit perm=execute all : all
    ...
  12. fapolicyd サービスを開始します。

    # systemctl start fapolicyd

検証

  1. たとえば、カスタムバイナリーが実行できることを確認します。

    $ /tmp/ls
    ls

関連情報

  • fapolicyd.rules(5 )および fapolicyd-cli(1) の man ページ
  • fapolicyd パッケージでインストールされるドキュメントは、/usr/share/fapolicyd/sample-rules/README-rules ファイルにあります。

13.5. fapolicyd 整合性チェックの有効化

デフォルトでは、fapolicyd は整合性チェックを実行しません。ファイルサイズまたは SHA-256 ハッシュのいずれかを比較して整合性チェックを実行するように fapolicyd を設定できます。Integrity Measurement Architecture (IMA) サブシステムを使用して整合性チェックを設定することもできます。

前提条件

  • fapolicyd フレームワークがシステムにデプロイされます。

手順

  1. 任意のテキストエディターで /etc/fapolicyd/fapolicyd.conf ファイルを開きます。以下に例を示します。

    # vi /etc/fapolicyd/fapolicyd.conf
  2. 整合性 オプションの値を none から sha256 に変更し、ファイルを保存してエディターを終了します。

    integrity = sha256
  3. fapolicyd サービスを再起動します。

    # systemctl restart fapolicyd

検証

  1. 検証に使用するファイルのバックアップを作成します。

    # cp /bin/more /bin/more.bak
  2. /bin/more バイナリーの内容を変更します。

    # cat /bin/less > /bin/more
  3. 変更したバイナリーを一般ユーザーとして使用します。

    # su example.user
    $ /bin/more /etc/redhat-release
    bash: /bin/more: Operation not permitted
  4. 変更を元に戻します。

    # mv -f /bin/more.bak /bin/more

13.7. 関連情報

  • man -k fapolicyd コマンドを使用して一覧表示される fapolicyd 関連の man ページ。
  • FOSDEM 2020 fapolicyd プレゼンテーション。

第14章 侵入型 USB デバイスに対するシステムの保護

USB デバイスは、spyware、malware、または trojans で読み込むことができます。これにより、データを盗んだり、システムが破損する可能性があります。Red Hat Enterprise Linux 管理者は、USBGuard でこのような USB 攻撃を防ぐことができます。

14.1. USBGuard

USBGuard ソフトウェアフレームワークを使用すると、カーネルの USB デバイス認証機能に基づいて許可されたデバイスおよび禁止されているデバイスの基本リストを使用して、侵入型 USB デバイスからシステムを保護できます。

USBGuard フレームワークは、次を提供します。

  • 動的対話およびポリシー強制向けの IPC (inter-process communication) インターフェースを使用したシステムサービスコンポーネント
  • 実行中の usbguard システムサービスと対話するコマンドラインインターフェース
  • USB デバイス認証ポリシーを記述するルール言語
  • 共有ライブラリーに実装されたシステムサービスコンポーネントと対話する C++ API

usbguard システムサービス設定ファイル (/etc/usbguard/usbguard-daemon.conf) には、IPC インターフェースを使用するためのユーザーおよびグループを認証するオプションが含まれます。

重要

システムサービスは、USBGuard パブリック IPC インターフェースを提供します。Red Hat Enterprise Linux では、このインターフェースへのアクセスはデフォルトで root ユーザーに限定されています。

IPC インターフェースへのアクセスを制限するには、IPCAccessControlFiles オプション (推奨)、IPCAllowedUsers オプション、および IPCAllowedGroups オプションを設定することを検討してください。

アクセス制御リスト (ACL) を未設定のままにしないでください。設定しないと、すべてのローカルユーザーに IPC インターフェイスが公開され、USB デバイスの認証状態を操作して USBGuard ポリシーを変更できるようになります。

14.2. USBGuard のインストール

この手順を使用して、USBGuard フレームワークをインストールし、開始します。

手順

  1. usbguard パッケージをインストールします。

    # dnf install usbguard
  2. 初期ルールセットを作成します。

    # usbguard generate-policy > /etc/usbguard/rules.conf
  3. usbguard デーモンを起動し、システムの起動時に自動的に起動することを確認します。

    # systemctl enable --now usbguard

検証

  1. usbguard サービスが実行していることを確認します。

    # systemctl status usbguard
    ● usbguard.service - USBGuard daemon
       Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled)
       Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago
         Docs: man:usbguard-daemon(8)
     Main PID: 6122 (usbguard-daemon)
        Tasks: 3 (limit: 11493)
       Memory: 1.2M
       CGroup: /system.slice/usbguard.service
               └─6122 /usr/sbin/usbguard-daemon -f -s -c /etc/usbguard/usbguard-daemon.conf
    
    Nov 07 09:44:06 localhost.localdomain systemd[1]: Starting USBGuard daemon...
    Nov 07 09:44:07 localhost.localdomain systemd[1]: Started USBGuard daemon.
  2. USBGuard が認識する USB デバイスの一覧を表示します。

    # usbguard list-devices
    4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...

関連情報

  • usbguard(1) および usbguard-daemon.conf(5) の man ページ

14.3. CLI で USB デバイスのブロックおよび認証

この手順では、usbguard コマンドを使用して USB デバイスを認証してブロックする方法を説明します。

前提条件

  • usbguard サービスがインストールされており、実行している。

手順

  1. USBGuard が認識する USB デバイスの一覧を表示します。

    # usbguard list-devices
    1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
    ...
    6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
  2. デバイス 6 を認証してシステムと対話します。

    # usbguard allow-device 6
  3. デバイス 6 の認証を解除し、削除します。

    # usbguard reject-device 6
  4. デバイス 6 の認可を解除し、保持します。

    # usbguard block-device 6
注記

USBGuard では、block および reject は以下の意味で使用されます。

  • block - 今は、このデバイスと対話しない
  • reject - このデバイスを、存在しないかのように無視する

関連情報

  • usbguard(1) の man ページ
  • usbguard --help コマンドを使用して一覧表示される組み込みヘルプ。

14.4. USB デバイスの永続的なブロックおよび認証

-p オプションを使用すると、USB デバイスをブロックして認証できます。これにより、デバイス固有のルールが現在のポリシーに追加されます。

前提条件

  • usbguard サービスがインストールされており、実行している。

手順

  1. usbguard デーモンがルールの書き込みを許可するように SELinux を設定します。

    1. usbguard に関連する semanage ブール値を表示します。

      # semanage boolean -l | grep usbguard
      usbguard_daemon_write_conf     (off  ,  off)  Allow usbguard to daemon write conf
      usbguard_daemon_write_rules    (on   ,   on)  Allow usbguard to daemon write rules
    2. オプション:usbguard_daemon_write_rules のブール値が無効になっている場合は、有効にします。

      # semanage boolean -m --on usbguard_daemon_write_rules
  2. USBGuard が認識する USB デバイスの一覧を表示します。

    # usbguard list-devices
    1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
    ...
    6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
  3. デバイス 6 を永続的に認証してシステムと対話します。

    # usbguard allow-device 6 -p
  4. デバイス 6 を永続的に認証し、削除します。

    # usbguard reject-device 6 -p
  5. デバイス 6 を永続的に承認し、保持します。

    # usbguard block-device 6 -p
注記

USBGuard では、block および reject は以下の意味で使用されます。

  • block - 今は、このデバイスと対話しない
  • reject - このデバイスを、存在しないかのように無視する

検証

  1. USBGuard ルールに変更が含まれていることを確認します。

    # usbguard list-rules

関連情報

  • usbguard(1) の man ページ
  • usbguard --help コマンドを使用して一覧表示される組み込みヘルプ。

14.5. USB デバイス用のカスタムポリシーの作成

以下の手順では、シナリオの要件を反映する USB デバイス用のルールセットを作成する手順を説明します。

前提条件

  • usbguard サービスがインストールされており、実行している。
  • /etc/usbguard/rules.conf ファイルには、usbguard generate-policy コマンドで生成した初期ルールセットが含まれます。

手順

  1. 現在接続している USB デバイスを認証するポリシーを作成し、生成されたルールを rules.conf ファイルに保存します。

    # usbguard generate-policy --no-hashes > ./rules.conf

    --no-hashes オプションは、デバイスのハッシュ属性を生成しません。構成設定のハッシュ属性は永続的ではない可能性があるため、回避してください。

  2. 選択したテキストエディターで rules.conf ファイルを編集します。次に例を示します。

    # vi ./rules.conf
  3. 必要に応じて、ルールを追加、削除、または編集します。たとえば、以下のルールを使用すると、大容量ストレージインターフェースが 1 つあるデバイスのみがシステムと対話できます。

    allow with-interface equals { 08:*:* }

    詳細なルール言語の説明とその他の例は、man ページの usbguard-rules.conf(5) を参照してください。

  4. 更新したポリシーをインストールします。

    # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
  5. usbguard デーモンを再起動して、変更を適用します。

    # systemctl restart usbguard

検証

  1. カスタムルールがアクティブポリシーにあることを確認します。以下に例を示します。

    # usbguard list-rules
    ...
    4: allow with-interface 08:*:*
    ...

関連情報

  • usbguard-rules.conf(5) man ページ

14.6. USB デバイス用に構造化されたカスタムポリシーの作成

カスタム USBGuard ポリシーは、/etc/usbguard/rules.d/ ディレクトリー内の複数の .conf ファイルで整理できます。次に、usbguard-daemon は、メインの rules.conf ファイルを、ディレクトリー内の .conf ファイルをアルファベット順で組み合わせます。

前提条件

  • usbguard サービスがインストールされており、実行している。

手順

  1. 現在接続している USB デバイスを認証するポリシーを作成し、生成されたルールを、新しい .conf ファイル (例えば policy.conf) ファイルに保存します。

    # usbguard generate-policy --no-hashes > ./policy.conf

    --no-hashes オプションは、デバイスのハッシュ属性を生成しません。構成設定のハッシュ属性は永続的ではない可能性があるため、回避してください。

  2. 任意のテキストエディターで rules.conf ファイルを編集します。次に例を示します。

    # vi ./policy.conf
    ...
    allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
    ...
  3. 選択した行を別を別の .conf ファイルに移動します。

    注記

    ファイル名の先頭にある 2 つの数字は、デーモンが設定ファイルを読み込む順序を指定します。

    たとえば、キーボードのルールを新規 .conf ファイルにコピーします。

    # grep "USB Keyboard" ./policy.conf > ./10keyboards.conf
  4. 新しいポリシーを /etc/usbguard/rules.d/ ディレクトリーにインストールします。

    # install -m 0600 -o root -g root 10keyboards.conf /etc/usbguard/rules.d/10keyboards.conf
  5. 残りの行をメインの rules.conf ファイルに移動します。

    # grep -v "USB Keyboard" ./policy.conf > ./rules.conf
  6. 残りのルールをインストールします。

    # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
  7. usbguard デーモンを再起動して、変更を適用します。

    # systemctl restart usbguard

検証

  1. アクティブな USBGuard ルールをすべて表示します。

    # usbguard list-rules
    ...
    15: allow id 04f2:0833 serial "" name "USB Keyboard" hash "kxM/iddRe/WSCocgiuQlVs6Dn0VEza7KiHoDeTz0fyg=" parent-hash "2i6ZBJfTl5BakXF7Gba84/Cp1gslnNc1DM6vWQpie3s=" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
    ...
  2. rules.conf ファイルと、/etc/usbguard/rules.d/ ディレクトリー内の .conf ファイルの内容をすべて表示します。

    # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf
  3. アクティブなルールに、ファイルのすべてのルールが正しく、正しい順序で含まれていることを確認します。

関連情報

  • usbguard-rules.conf(5) man ページ

14.7. USBGuard IPC インターフェースを使用するユーザーおよびグループの認証

この手順を使用して、特定のユーザーまたはグループが USBGuard のパブリック IPC インターフェースを使用するように認証します。デフォルトでは、root ユーザーだけがこのインターフェースを使用できます。

前提条件

  • usbguard サービスがインストールされており、実行している。
  • /etc/usbguard/rules.conf ファイルには、usbguard generate-policy コマンドで生成した初期ルールセットが含まれます。

手順

  1. 任意のテキストエディターで /etc/usbguard/usbguard-daemon.conf ファイルを編集します。

    # vi /etc/usbguard/usbguard-daemon.conf
  2. たとえば、wheel グループの全ユーザーが IPC インターフェースを使用できるように、ルールがある行を追加して、ファイルを保存します。

    IPCAllowGroups=wheel
  3. usbguard コマンドで、ユーザーまたはグループを追加することもできます。たとえば、次のコマンドを使用すると、joesec ユーザーが Devices セクションおよび Exceptions セクションに完全アクセスできます。さらに、joesec は現行ポリシーの一覧表示および変更を行うことができます。

    # usbguard add-user joesec --devices ALL --policy modify,list --exceptions ALL

    joesec ユーザーに付与されたパーミッションを削除するには、usbguard remove-user joesec コマンドを使用します。

  4. usbguard デーモンを再起動して、変更を適用します。

    # systemctl restart usbguard

関連情報

  • usbguard(1) および usbguard-rules.conf(5) の man ページ

14.8. Linux 監査ログへの USBguard 認証イベントの記録

以下の手順に従って、USBguard 認証イベントのログと標準の Linux 監査ログを 1 つにまとめます。デフォルトでは、usbguard デーモンは /var/log/usbguard/usbguard-audit.log ファイルにイベントを記録します。

前提条件

  • usbguard サービスがインストールされており、実行している。
  • auditd サービスが実行している。

手順

  1. usbguard-daemon.conf ファイルを、選択したテキストエディターで編集します。

    # vi /etc/usbguard/usbguard-daemon.conf
  2. AuditBackend オプションを、FileAudit から LinuxAudit に変更します。

    AuditBackend=LinuxAudit
  3. usbguard デーモンを再起動して、設定変更を適用します。

    # systemctl restart usbguard

検証

  1. 監査 デーモンログを USB 認証イベントに対してクエリーします。次に例を示します。

    # ausearch -ts recent -m USER_DEVICE

関連情報

  • usbguard-daemon.conf(5) の man ページ

14.9. 関連情報

  • usbguard(1)usbguard-rules.conf(5)usbguard-daemon(8)、および usbguard-daemon.conf(5) の man ページ
  • USBGuard ホームページ

第15章 リモートロギングソリューションの設定

環境内の各種マシンからのログをロギングサーバーに集中的に記録するために、クライアントシステムからサーバーに特定の基準に合致するログを記録するように Rsyslog アプリケーションを設定できます。

15.1. Rsyslog ロギングサービス

Rsyslog アプリケーションは、systemd-journald サービスと組み合わせて、Red Hat Enterprise Linux でローカルおよびリモートのロギングサポートを提供します。rsyslogd デーモンは、ジャーナルから systemd-journald サービスが受信した syslog メッセージを継続的に読み取り、rsyslogd がこのような syslog イベントにフィルターを設定して処理し、rsyslog ログファイルに記録するか、その設定に応じて他のサービスに転送します。

rsyslogd デーモンは、拡張されたフィルタリング、暗号化で保護されたメッセージのリレー、入出力モジュール、TCP プロトコルおよび UDP プロトコルを使用した転送のサポートも提供します。

rsyslog の主な設定ファイルである /etc/rsyslog.conf では、どの rsyslogd がメッセージを処理するかに応じてルールを指定できます。通常は、ソースおよびトピック (ファシリティー) 別および緊急度 (優先度) 別にメッセージを分類し、メッセージがその基準に合致したときに実行するアクションを割り当てることができます。

/etc/rsyslog.conf では、rsyslogd が維持するログファイルの一覧も確認できます。ほとんどのログファイルは /var/log/ ディレクトリーにあります。httpdsamba などの一部のアプリケーションは、ログファイルを /var/log/ 内のサブディレクトリーに保存します。

関連情報

  • man ページの rsyslogd(8) および rsyslog.conf(5 )
  • /usr/share/doc/rsyslog/html/index.html ファイルの rsyslog-doc パッケージでインストールされるドキュメント

15.2. Rsyslog ドキュメントのインストール

Rsyslog アプリケーションには、https://www.rsyslog.com/doc/ で利用可能な詳細なオンラインドキュメントがありますが、rsyslog-doc ドキュメントパッケージをローカルにインストールすることもできます。

前提条件

  • システムで AppStream リポジトリーをアクティベートしている。
  • sudo を使用して新規パッケージをインストールする権限がある。

手順

  • rsyslog-doc パッケージをインストールします。

    # dnf install rsyslog-doc

検証

  • 任意のブラウザーで /usr/share/doc/rsyslog/html/index.html ファイルを開きます。以下に例を示します。

    $ firefox /usr/share/doc/rsyslog/html/index.html &

15.3. TCP でのリモートロギング用のサーバーの設定

Rsyslog アプリケーションを使用すると、ロギングサーバーを実行し、個別のシステムがログファイルをロギングサーバーに送信するように設定できます。TCP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。

Rsyslog アプリケーションを使用すると、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを維持できます。サーバーが利用できない場合にメッセージが失われないようにするには、転送アクションのアクションキューを設定します。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは、UDP プロトコルを使用する接続用に設定できないことに注意してください。

omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。このプラグインは組み込まれているため、読み込む必要はありません。

デフォルトでは、rsyslog はポート 514 で TCP を使用します。

前提条件

  • rsyslog がサーバーシステムにインストールされている。
  • サーバーに root としてログインしている。
  • policycoreutils-python-utils パッケージは、semanage コマンドを使用して任意の手順でインストールします。
  • firewalld サービスが実行している。

手順

  1. オプション:rsyslog トラフィックに別のポートを使用するには、SELinux タイプ syslogd_port_t をポートに追加します。たとえば、ポート 30514 を有効にします。

    # semanage port -a -t syslogd_port_t -p tcp 30514
  2. オプション:rsyslog トラフィックに別のポートを使用するには、firewalld がそのポートでの着信 rsyslog トラフィックを許可するように設定します。たとえば、ポート30514 で TCP トラフィックを許可します。

    # firewall-cmd --zone=<zone-name> --permanent --add-port=30514/tcp
    success
    # firewall-cmd --reload
  3. /etc/rsyslog.d/ ディレクトリーに新規ファイル (例: remotelog.conf) を作成し、以下のコンテンツを挿入します。

    # Define templates before the rules that use them
    # Per-Host templates for remote systems
    template(name="TmplAuthpriv" type="list") {
        constant(value="/var/log/remote/auth/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    template(name="TmplMsg" type="list") {
        constant(value="/var/log/remote/msg/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    # Provides TCP syslog reception
    module(load="imtcp")
    
    # Adding this ruleset to process remote messages
    ruleset(name="remote1"){
         authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
          *.info;mail.none;authpriv.none;cron.none
    action(type="omfile" DynaFile="TmplMsg")
    }
    
    input(type="imtcp" port="30514" ruleset="remote1")
  4. /etc/rsyslog.d/remotelog.conf ファイルへの変更を保存します。
  5. /etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  6. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

    # systemctl status rsyslog
  7. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  8. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog

環境内の他のシステムからログファイルを受け取り、保存するように、ログサーバーが設定されています。

関連情報

  • rsyslogd(8)rsyslog.conf(5)semanage(8)、および firewall-cmd(1) man ページ。
  • /usr/share/doc/rsyslog/html/index.html ファイルの rsyslog-doc パッケージでインストールされるドキュメント

15.4. TCP 経由のサーバーへのリモートロギングの設定

以下の手順に従って、TCP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

  • rsyslog パッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。
  • リモートロギング用にサーバーを設定している。
  • 指定したポートが SELinux で許可され、ファイアウォールで開いている。
  • システムには、policycoreutils-python-utils パッケージが含まれています。このパッケージは、標準以外のポートを SELinux 設定に追加するための semanage コマンドを提供します。

手順

  1. /etc/rsyslog.d/ ディレクトリーに新しいファイルを作成します(例: 10-remotelog.conf )、以下の内容を挿入します。

    *.* action(type="omfwd"
          queue.type="linkedlist"
          queue.filename="example_fwd"
          action.resumeRetryCount="-1"
          queue.saveOnShutdown="on"
          target="example.com" port="30514" protocol="tcp"
         )

    詳細は以下のようになります。

    • queue.type="linkedlist" は、LinkedList インメモリーキューを有効にします。
    • queue.filename はディスクストレージを定義します。バックアップファイルは、前のグローバルの workDirectory ディレクティブで指定された作業ディレクトリーに example_fwd 接頭辞を付けて作成されます。
    • action.resumeRetryCount -1 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
    • rsyslog がシャットダウンすると、有効になっている queue.saveOnShutdown="on" はインメモリーデータを保存します。
    • 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。

      この設定では、rsyslog はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域が rsyslog で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

    注記

    rsyslog は、設定ファイル /etc/rsyslog.d/ を辞書式順序で処理します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • rsyslogd(8) および rsyslog.conf(5) man ページ。
  • /usr/share/doc/rsyslog/html/index.html ファイルの rsyslog-doc パッケージでインストールされるドキュメント

15.5. TLS 暗号化リモートロギングの設定

デフォルトでは、Rsyslog はプレーンテキスト形式でリモートロギング通信を送信します。シナリオでこの通信チャネルのセキュリティーを確保する必要がある場合は、TLS を使用して暗号化できます。

TLS を介した暗号化されたトランスポートを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。

ossl ネットワークストリームドライバー (OpenSSL) または gtls ストリームドライバー (GnuTLS) のいずれかを使用できます。

注記

ネットワークに接続されていない、厳格な認可を受けているなど、セキュリティーが強化された別のシステムがある場合は、その別のシステムを認証局 (CA) として使用します。

前提条件

  • クライアントシステムとサーバーシステムの両方に root にアクセスできる。
  • rsyslog パッケージおよび rsyslog-openssl パッケージは、サーバーおよびクライアントシステムにインストールされている。
  • gtls ネットワークストリームドライバーを使用する場合は、rsyslog-openssl の代わりに rsyslog-gnutls をインストールしてください。
  • certtool を使用して証明書を生成する場合は、gnutls-utils をインストールします。
  • ログサーバーの /etc/pki/ca-trust/source/anchors/ ディレクトリーには、次の証明書があり、update-ca-trust コマンドを使用してシステム設定を更新します。

    • ca-cert.pem - ログサーバーとクライアントで鍵と証明書を検証できる CA 証明書。
    • server-cert.pem - ロギングサーバーの公開鍵。
    • server-key.pem - ロギングサーバーの秘密鍵。
  • ログクライアントでは、次の証明書が /etc/pki/ca-trust/source/anchors/ ディレクトリーにあり、update-ca-trust を使用してシステム設定を更新します。

    • ca-cert.pem - ログサーバーとクライアントで鍵と証明書を検証できる CA 証明書。
    • client-cert.pem - クライアントの公開鍵。
    • client-key.pem - クライアントの秘密鍵。

手順

  1. クライアントシステムから暗号化したログを受信するようにサーバーを設定します。

    1. /etc/rsyslog.d/ディレクトリーに、新規ファイル (securelogser.conf など) を作成します。
    2. 通信を暗号化するには、設定ファイルに、サーバーの証明書ファイルへのパス、選択した認証方法、および TLS 暗号化に対応するストリームドライバーが含まれている必要があります。/etc/rsyslog.d/securelogser.conf に以下の行を追加します。

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/server-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/server-key.pem"
      )
      
      # TCP listener
      module(
        load="imtcp"
        PermittedPeer=["client1.example.com", "client2.example.com"]
        StreamDriver.AuthMode="x509/name"
        StreamDriver.Mode="1"
        StreamDriver.Name="ossl"
      )
      
      # Start up listener at port 514
      input(
        type="imtcp"
        port="514"
      )
      注記

      GnuTLS ドライバーが必要な場合は、StreamDriver.Name="gtls" 設定オプションを使用します。x509/name よりも厳密ではない認証モードの詳細は、rsyslog-doc にインストールされているドキュメントを参照してください。

    3. 変更を /etc/rsyslog.d/securelogser.conf ファイルに保存します。
    4. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内のすべてのファイルを確認します。

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.
    5. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog
    6. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    7. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog
  2. 暗号化したログをサーバーに送信するようにクライアントを設定するには、以下のコマンドを実行します。

    1. クライアントシステムで、/etc/rsyslog.d/ディレクトリーに、新規ファイル (securelogcli.conf など) を作成します。
    2. /etc/rsyslog.d/securelogcli.conf に以下の行を追加します。

      # Set certificate files
      global(
        DefaultNetstreamDriverCAFile="/etc/pki/ca-trust/source/anchors/ca-cert.pem"
        DefaultNetstreamDriverCertFile="/etc/pki/ca-trust/source/anchors/client-cert.pem"
        DefaultNetstreamDriverKeyFile="/etc/pki/ca-trust/source/anchors/client-key.pem"
      )
      
      
      # Set up the action for all messages
      *.* action(
        type="omfwd"
        StreamDriver="ossl"
        StreamDriverMode="1"
        StreamDriverPermittedPeers="server.example.com"
        StreamDriverAuthMode="x509/name"
        target="server.example.com" port="514" protocol="tcp"
      )
      注記

      GnuTLS ドライバーが必要な場合は、StreamDriver.Name="gtls" 設定オプションを使用します。

    3. 変更を /etc/rsyslog.d/securelogser.conf ファイルに保存します。
    4. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内のその他のファイルを確認します。

      # rsyslogd -N 1
      rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
      rsyslogd: End of config validation run. Bye.
    5. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

      # systemctl status rsyslog
    6. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    7. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • man ページの certtool(1)openssl(1)update-ca-trust(8)rsyslogd(8)、および rsyslog.conf(5)
  • rsyslog-doc パッケージでインストールされるドキュメントは、/usr/share/doc/rsyslog/html/index.html にあります。
  • Using the Logging System Role

15.6. UDP でリモートロギング情報を受信するためのサーバー設定

Rsyslog アプリケーションを使用すると、リモートシステムからロギング情報を受信するようにシステムを設定できます。UDP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。受信サーバーは、クライアントシステムが送信したログの収集および分析を行います。デフォルトでは、rsyslog はポート 514 で UDP を使用して、リモートシステムからログ情報を受信します。

以下の手順に従って、UDP プロトコルでクライアントシステムが送信したログの収集および分析を行うサーバーを設定します。

前提条件

  • rsyslog がサーバーシステムにインストールされている。
  • サーバーに root としてログインしている。
  • policycoreutils-python-utils パッケージは、semanage コマンドを使用して任意の手順でインストールします。
  • firewalld サービスが実行している。

手順

  1. オプション:デフォルトのポート 514 以外の rsyslog トラフィックに別のポートを使用するには、次のコマンドを実行します。

    1. SELinux ポリシー設定に syslogd_port_t SELinux タイプを追加し、portnorsyslog で使用するポート番号に置き換えます。

      # semanage port -a -t syslogd_port_t -p udp portno
    2. rsyslog の受信トラフィックを許可するように firewalld を設定します。portno はポート番号に、zonersyslog が使用するゾーンに置き換えます。

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
      # firewall-cmd --reload
    3. ファイアウォールルールを再読み込みします。

      # firewall-cmd --reload
  2. /etc/rsyslog.d/ ディレクトリーに .conf の新規ファイル (例: remotelogserv.conf) を作成し、以下のコンテンツを挿入します。

    # Define templates before the rules that use them
    # Per-Host templates for remote systems
    template(name="TmplAuthpriv" type="list") {
        constant(value="/var/log/remote/auth/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    template(name="TmplMsg" type="list") {
        constant(value="/var/log/remote/msg/")
        property(name="hostname")
        constant(value="/")
        property(name="programname" SecurePath="replace")
        constant(value=".log")
        }
    
    # Provides UDP syslog reception
    module(load="imudp")
    
    # This ruleset processes remote messages
    ruleset(name="remote1"){
         authpriv.*   action(type="omfile" DynaFile="TmplAuthpriv")
          *.info;mail.none;authpriv.none;cron.none
    action(type="omfile" DynaFile="TmplMsg")
    }
    
    input(type="imudp" port="514" ruleset="remote1")

    514 は、rsyslog がデフォルトで使用するポート番号です。代わりに別のポートを指定できます。

  3. /etc/rsyslog.conf ファイルの構文と /etc/rsyslog.d/ ディレクトリー内の全 .conf ファイルを確認します。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  4. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  5. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog

関連情報

  • rsyslogd(8)rsyslog.conf(5)semanage(8)、および firewall-cmd(1) man ページ。
  • /usr/share/doc/rsyslog/html/index.html ファイルの rsyslog-doc パッケージでインストールされるドキュメント

15.7. UDP 経由のサーバーへのリモートロギングの設定

以下の手順に従って、UDP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

手順

  1. /etc/rsyslog.d/ ディレクトリーに新しい .conf ファイルを作成します(例: 10-remotelogcli.conf )、以下のコンテンツを挿入します。

    *.* action(type="omfwd"
          queue.type="linkedlist"
          queue.filename="example_fwd"
          action.resumeRetryCount="-1"
          queue.saveOnShutdown="on"
          target="example.com" port="portno" protocol="udp"
         )

    詳細は以下のようになります。

    • queue.type="linkedlist" は、LinkedList インメモリーキューを有効にします。
    • queue.filename はディスクストレージを定義します。バックアップファイルは、前のグローバルの workDirectory ディレクティブで指定された作業ディレクトリーに example_fwd 接頭辞を付けて作成されます。
    • action.resumeRetryCount -1 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
    • rsyslog がシャットダウンすると、有効になっている queue.saveOnShutdown="on" はインメモリーデータを保存します。
    • portno は、rsyslog で使用するポート番号です。デフォルト値は 514 です。
    • 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。

      この設定では、rsyslog はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域が rsyslog で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

    注記

    rsyslog は、設定ファイル /etc/rsyslog.d/ を辞書式順序で処理します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  3. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、/var/log/remote/msg/hostname/root.log ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • rsyslogd(8) および rsyslog.conf(5) man ページ。
  • rsyslog-doc パッケージでインストールされるドキュメントは、/usr/share/doc/rsyslog/html/index.html にあります。

15.8. rsyslog の負荷分散ヘルパー

RebindInterval 設定では、現行接続を切断して再確立する間隔を指定します。この設定は、TCP、UDP、および RELP のトラフィックに適用されます。ロードバランサーはこれを新しい接続と認識し、メッセージを別の物理ターゲットシステムに転送します。

RebindInterval 設定は、ターゲットシステムの IP アドレスが変更した場合にシナリオで役に立ちます。Rsyslog アプリケーションは、接続の確立時に IP アドレスをキャッシュするため、メッセージは同じサーバーに送信されます。IP アドレスが変更すると、Rsyslog サービスが再起動するまで UDP パケットが失われます。接続を再確立すると、IP が DNS により再度解決されます。

action(type=”omfwd” protocol=”tcp” RebindInterval=”250” target=”example.com” port=”514” …)

action(type=”omfwd” protocol=”udp” RebindInterval=”250” target=”example.com” port=”514” …)

action(type=”omrelp” RebindInterval=”250” target=”example.com” port=”6514” …)

15.9. 信頼できるリモートロギングの設定

Reliable Event Logging Protocol (RELP) を使用すると、メッセージ損失のリスクを大幅に軽減して TCP で syslog メッセージを送受信できます。RELP は、信頼できるイベントメッセージを配信するので、メッセージ損失が許されない環境で有用です。RELP を使用するには、imrelp の入力モジュール (サーバー上での実行とログの受信) と omrelp 出力モジュール (クライアント上での実行とロギングサーバーへのログの送信) を設定します。

前提条件

  • rsyslog パッケージ、librelp パッケージ、および rsyslog-relp パッケージをサーバーおよびクライアントシステムにインストールしている。
  • 指定したポートが SELinux で許可され、ファイアウォール設定で開放されている。

手順

  1. 信頼できるリモートロギング用にクライアントシステムを設定します。

    1. クライアントシステムの /etc/rsyslog.d/ ディレクトリーに、relpclient.conf などと名前を指定して新しい .conf ファイルを作成し、以下のコンテンツを挿入します。

      module(load="omrelp")
      *.* action(type="omrelp" target="_target_IP_" port="_target_port_")

      詳細は以下のようになります。

      • target_IP は、ロギングサーバーの IP アドレスに置き換えます。
      • target_port はロギングサーバーのポートに置き換えます。
    2. 変更を /etc/rsyslog.d/relpclient.conf ファイルに保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    4. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog
  2. 信頼できるリモートロギング用にサーバーシステムを設定します。

    1. サーバーシステムの /etc/rsyslog.d/ ディレクトリーに、relpserv.conf などと名前を指定して新しい .conf ファイルを作成し、以下のコンテンツを挿入します。

      ruleset(name="relp"){
      *.* action(type="omfile" file="_log_path_")
      }
      
      
      module(load="imrelp")
      input(type="imrelp" port="_target_port_" ruleset="relp")

      詳細は以下のようになります。

      • log_path は、メッセージを保存するパスを指定します。
      • target_port はロギングサーバーのポートに置き換えます。クライアント設定ファイルと同じ値を使用します。
    2. /etc/rsyslog.d/relpserv.conf ファイルへの変更を保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    4. オプション:rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、指定された log_path でログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • rsyslogd(8) および rsyslog.conf(5) man ページ。
  • /usr/share/doc/rsyslog/html/index.html ファイルの rsyslog-doc パッケージでインストールされるドキュメント

15.10. サポート対象の Rsyslog モジュール

Rsyslog アプリケーションの機能を拡張するには、特定のモジュールを使用できます。モジュールは、追加の入力(入力モジュール)、出力(出力モジュール)、およびその他の機能を提供します。モジュールは、モジュールのロード後に利用可能な設定ディレクティブを追加で提供することもできます。

以下のコマンドを入力して、システムにインストールされている入出力モジュールを一覧表示できます。

# ls /usr/lib64/rsyslog/{i,o}m*

rsyslog -doc パッケージのインストール後に、/usr/share/doc/rsyslog/html/configuration/modules/idx_output.html ファイルで利用可能な rsyslog モジュールの一覧を表示できます。

15.11. 関連情報

第16章 Logging システムロールの使用

システム管理者は、Logging システムロールを使用して、RHEL ホストをロギングサーバーとして設定し、多くのクライアントシステムからログを収集できます。

16.1. Logging システムロール

Logging システムロールを使用すると、ローカルおよびリモートホストにロギング設定をデプロイできます。

Logging システムロールを 1 つ以上のシステムに適用するには、Playbook でロギング設定を定義します。Playbook は、1 つ以上の play の一覧です。Playbook は YAML 形式で表現され、人が判読できるようになっています。Playbook の詳細は、Ansible ドキュメントの 「Working with playbooks」 を参照してください。

Playbook に従って設定するシステムのセットは、インベントリーファイル で定義されます。インベントリーの作成および使用に関する詳細は、Ansible ドキュメントの 「How to build your inventory」 を参照してください。

ロギングソリューションは、ログと複数のログ出力を読み取る複数の方法を提供します。

たとえば、ロギングシステムは以下の入力を受け取ることができます。

  • ローカルファイル
  • systemd/journal
  • ネットワーク上で別のロギングシステム

さらに、ロギングシステムでは以下を出力できます。

  • /var/logディレクトリーのローカルファイルに保存されているログ
  • Elasticsearch に送信されたログ
  • 別のロギングシステムに転送されたログ

Logging システムロールでは、シナリオに合わせて入出力を組み合わせることができます。たとえば、journal からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。

16.2. Logging システムロールのパラメーター

Logging システムロール Playbook では、logging_inputs パラメーターで入力を、logging_outputs パラメーターで出力を、そして logging_flows パラメーターで入力と出力の関係を定義します。Logging システムロールは、ロギングシステムの追加設定オプションで、上記の変数を処理します。暗号化を有効にすることもできます。

注記

現在、Logging システムロールで利用可能な唯一のロギングシステムは Rsyslog です。

  • logging_inputs:ロギングソリューションの入力一覧。

    • name:入力の一意の名前。logging_flows での使用: 入力一覧および生成された config ファイル名の一部で使用されます。
    • type:入力要素のタイプ。type は、roles/rsyslog/{tasks,vars}/inputs/ のディレクトリー名に対応するタスクタイプを指定します。

      • basics:systemd ジャーナルまたは unix ソケットからの入力を設定する入力。

        • kernel_message:true に設定されている場合は、imklog をロードします。デフォルトは false です。
        • use_imuxsock:imjournal の代わりに imuxsock を使用します。デフォルトは false です。
        • ratelimit_burst:ratelimit_interval 内に出力できるメッセージの最大数。use_imuxsock が false の場合、デフォルトで 20000 に設定されます。use_imuxsock が true の場合、デフォルトで 200 に設定されます。
        • ratelimit_interval:ratelimit_burst を評価する間隔。use_imuxsock が false の場合、デフォルトで 600 秒に設定されます。use_imuxsock が true の場合、デフォルトで 0 に設定されます。0 はレート制限がオフであることを示します。
        • persist_state_interval:ジャーナルの状態は、value メッセージごとに永続化されます。デフォルトは 10 です。use_imuxsock が false の場合のみ、有効です。
      • files:ローカルファイルからの入力を設定する入力。
      • remote:ネットワークを介して他のロギングシステムからの入力を設定する入力。
    • state:設定ファイルの状態。present または absent。デフォルトは present です。
  • logging_outputs:ロギングソリューションの出力一覧。

    • files:ローカルファイルへの出力を設定する出力。
    • forwards:別のロギングシステムへの出力を設定する出力。
    • remote_files:別のロギングシステムからの出力をローカルファイルに設定する出力。
  • logging_flows:logging_inputs および logging_outputs の関係を定義するフローの一覧。logging_flows 変数には以下が含まれます。

    • name:フローの一意の名前。
    • inputs:logging_inputs 名の値の一覧。
    • outputs:logging_outputs 名の値の一覧。

関連情報

  • rhel-system-roles パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html)

16.3. ローカルの Logging システムロールの適用

以下の手順に従って、Ansible Playbook を準備および適用し、別個のマシンにロギングソリューションを設定します。各マシンはログをローカルに記録します。

前提条件

  • Logging システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • コントロールノード (このシステムから Red Hat Ansible Core は他のシステムを設定) へのアクセスおよびパーミッション。

    コントロールノードに、

    • ansible-core パッケージおよび rhel-system-roles パッケージがインストールされている。
重要

RHEL 8.0-8.5 は、Ansible に基づく自動化用に Ansible Engine 2.9 が含まれる別の Ansible リポジトリーへのアクセスを提供していました。Ansible Engine には、ansibleansible-playbookdockerpodman などのコネクター、多くのプラグインやモジュールなどのコマンドラインユーティリティーが含まれます。Ansible Engine の取得およびインストール方法の詳細は、ナレッジベースの記事「 How to download and install Red Hat Ansible Engine 」を参照してください。

RHEL 8.6 および 9.0 では、Ansible Core が導入されました( ansible-core パッケージとして提供)。これには、Ansible コマンドラインユーティリティー、コマンド、およびビルトイン Ansible プラグインの小規模なセットが含まれます。RHEL は AppStream リポジトリーを介してこのパッケージを提供し、サポート範囲が限定されています。詳細は、ナレッジベース の記事「RHEL 9 および RHEL 8.6 以降の AppStream リポジトリーに含まれる Ansible Core パッケージのサポート範囲」を参照し てください。

  • 管理対象ノードが記載されているインベントリーファイルがある。
注記

デプロイメント時にシステムロールがrsyslogをインストールするため、rsyslogパッケージをインストールする必要はありません。

手順

  1. 必要なロールを定義する Playbook を作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      # vi logging-playbook.yml
    2. 以下の内容を挿入します。

      ---
      - name: Deploying basics input and implicit files output
        hosts: all
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: system_input
              type: basics
          logging_outputs:
            - name: files_output
              type: files
          logging_flows:
            - name: flow1
              inputs: [system_input]
              outputs: [files_output]
  2. 特定のインベントリーで Playbook を実行します。

    # ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml

    詳細は以下のようになります。

    • inventory-file はインベントリーファイルに置き換えます。
    • logging-playbook.yml は、使用する Playbook に置き換えます。

検証

  1. /etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  2. システムがログにメッセージを送信していることを確認します。

    1. テストメッセージを送信します。

      # logger test
    2. /var/log/messages ログ を表示します。以下に例を示します。

      # cat /var/log/messages
      Aug  5 13:48:31 hostname root[6778]: test

      `hostname` はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

16.4. ローカルの Logging システムロールでのログのフィルタリング

rsyslog プロパティーベースのフィルターをもとにログをフィルターするロギングソリューションをデプロイできます。

前提条件

  • Logging システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • コントロールノード (このシステムから Red Hat Ansible Core は他のシステムを設定) へのアクセスおよびパーミッション。

    コントロールノードに、

    • Red Hat Ansible Core がインストールされている。
    • rhel-system-roles パッケージがインストールされている。
    • 管理対象ノードが記載されているインベントリーファイルがある。
注記

デプロイメント時にシステムロールが rsyslog をインストールするため、rsyslog パッケージをインストールする必要はありません。

手順

  1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

    ---
    - name: Deploying files input and configured files output
      hosts: all
      roles:
        - linux-system-roles.logging
      vars:
        logging_inputs:
          - name: files_input
            type: basics
        logging_outputs:
          - name: files_output0
            type: files
            property: msg
            property_op: contains
            property_value: error
            path: /var/log/errors.log
          - name: files_output1
            type: files
            property: msg
            property_op: "!contains"
            property_value: error
            path: /var/log/others.log
        logging_flows:
          - name: flow0
            inputs: [files_input]
            outputs: [files_output0, files_output1]

    この設定を使用すると、error 文字列を含むメッセージはすべて /var/log/errors.log に記録され、その他のメッセージはすべて /var/log/others.log に記録されます。

    error プロパティーの値はフィルタリングする文字列に置き換えることができます。

    設定に合わせて変数を変更できます。

  2. オプション:Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file /path/to/file/playbook.yml

検証

  1. /etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  2. システムが error 文字列を含むメッセージをログに送信していることを確認します。

    1. テストメッセージを送信します。

      # logger error
    2. 以下のように /var/log/errors.log ログを表示します。

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error

      hostname はクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • rhel-system-roles パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html)

16.5. Logging システムロールを使用したリモートロギングソリューションの適用

以下の手順に従って、Red Hat Ansible Core Playbook を準備および適用し、リモートロギングソリューションを設定します。この Playbook では、1 つ以上のクライアントが systemd-journal からログを取得し、リモートサーバーに転送します。サーバーは、remote_rsyslog および remote_files からリモート入力を受信し、リモートホスト名によって名付けられたディレクトリーのローカルファイルにログを出力します。

前提条件

  • Logging システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • コントロールノード (このシステムから Red Hat Ansible Core は他のシステムを設定) へのアクセスおよびパーミッション。

    コントロールノードに、

    • ansible-core パッケージおよび rhel-system-roles パッケージがインストールされている。
    • 管理対象ノードが記載されているインベントリーファイルがある。
注記

デプロイメント時にシステムロールが rsyslog をインストールするため、rsyslog パッケージをインストールする必要はありません。

手順

  1. 必要なロールを定義する Playbook を作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      # vi logging-playbook.yml
    2. 以下の内容をファイルに挿入します。

      ---
      - name: Deploying remote input and remote_files output
        hosts: server
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: remote_udp_input
              type: remote
              udp_ports: [ 601 ]
            - name: remote_tcp_input
              type: remote
              tcp_ports: [ 601 ]
          logging_outputs:
            - name: remote_files_output
              type: remote_files
          logging_flows:
            - name: flow_0
              inputs: [remote_udp_input, remote_tcp_input]
              outputs: [remote_files_output]
      
      - name: Deploying basics input and forwards output
        hosts: clients
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: basic_input
              type: basics
          logging_outputs:
            - name: forward_output0
              type: forwards
              severity: info
              target: _host1.example.com_
              udp_port: 601
            - name: forward_output1
              type: forwards
              facility: mail
              target: _host1.example.com_
              tcp_port: 601
          logging_flows:
            - name: flows0
              inputs: [basic_input]
              outputs: [forward_output0, forward_output1]
      
      [basic_input]
      [forward_output0, forward_output1]

      host1.example.com はロギングサーバーに置き換えます。

      注記

      必要に応じて、Playbook のパラメーターを変更することができます。

      警告

      ロギングソリューションは、サーバーまたはクライアントシステムの SELinux ポリシーで定義され、ファイアウォールで開放されたポートでしか機能しません。デフォルトの SELinux ポリシーには、ポート 601、514、6514、10514、および 20514 が含まれます。別のポートを使用するには、クライアントシステムおよびサーバーシステムで SELinux ポリシーを変更 します。システムロールを使用したファイアウォールの設定は、まだサポートされていません。

  2. サーバーおよびクライアントを一覧表示するインベントリーファイルを作成します。

    1. 新しいファイルを作成してテキストエディターで開きます。以下に例を示します。

      # vi inventory.ini
    2. 以下のコンテンツをインベントリーファイルに挿入します。

      [servers]
      server ansible_host=host1.example.com
      [clients]
      client ansible_host=host2.example.com

      ここで、

      • host1.example.com はロギングサーバーです。
      • host2.example.com はロギングクライアントです。
  3. インベントリーで Playbook を実行します。

    # ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml

    ここで、

    • inventory.ini はインベントリーファイルに置き換えます。
    • logging-playbook.yml は作成した Playbook に置き換えます。

検証

  1. クライアントとサーバーシステムの両方で、/etc/rsyslog.conf ファイルの構文をテストします。

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  2. クライアントシステムがサーバーにメッセージを送信することを確認します。

    1. クライアントシステムで、テストメッセージを送信します。

      # logger test
    2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

      # cat /var/log/messages
      Aug  5 13:48:31 host2.example.com root[6778]: test

      host2.example.com は、クライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

16.6. TLS でのロギングシステムロールの使用

Transport Layer Security (TLS) は、コンピューターネットワーク上で安全に通信するために設計された暗号プロトコルです。

管理者は、Logging RHEL システムロールを使用し、Red Hat Ansible Automation Platform を使用したセキュアなログ転送を設定できます。

16.6.1. TLS を使用したクライアントロギングの設定

Logging システムロールを使用して、ローカルマシンにログインしている RHEL システムでロギングを設定し、Ansible Playbook を実行して、ログを TLS でリモートロギングシステムに転送できます。

この手順では、Ansible インベントリーの client グループ内の全ホストに TLS を設定します。TLS プロトコルは、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • TLS を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying files input and forwards output with certs
      hosts: clients
      roles:
        - rhel-system-roles.logging
      vars:
        logging_pki_files:
          - ca_cert_src: /local/path/to/ca_cert.pem
            cert_src: /local/path/to/cert.pem
            private_key_src: /local/path/to/key.pem
        logging_inputs:
          - name: input_name
            type: files
            input_log_path: /var/log/containers/*.log
        logging_outputs:
          - name: output_name
            type: forwards
            target: your_target_host
            tcp_port: 514
            tls: true
            pki_authmode: x509/name
            permitted_server: 'server.example.com'
        logging_flows:
          - name: flow_name
            inputs: [input_name]
            outputs: [output_name]

    Playbook は以下のパラメーターを使用します。

    logging_pki_files
    このパラメーターを使用して、TLS を設定し、ca_cert_srccert_src および private_key_src パラメーターを指定する必要があります。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    tls
    このパラメーターを使用すると、ネットワーク経由でログを安全に転送できるようになります。セキュアなラッパーが必要ない場合は、tls: true と設定できます。
  2. Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

16.6.2. TLS を使用したサーバーロギングの設定

Logging システムロールを使用して、RHEL システムのログインをサーバーとして設定し、Ansible Playbook を実行して TLS でリモートロギングシステムからログを受信できます。

以下の手順では、Ansible インベントリーの server グループ内の全ホストに TLS を設定します。

前提条件

  • TLS を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying remote input and remote_files output with certs
      hosts: server
      roles:
        - rhel-system-roles.logging
      vars:
        logging_pki_files:
          - ca_cert_src: /local/path/to/ca_cert.pem
            cert_src: /local/path/to/cert.pem
            private_key_src: /local/path/to/key.pem
        logging_inputs:
          - name: input_name
            type: remote
            tcp_ports: 514
            tls: true
            permitted_clients: ['clients.example.com']
        logging_outputs:
          - name: output_name
            type: remote_files
            remote_log_path: /var/log/remote/%FROMHOST%/%PROGRAMNAME:::secpath-replace%.log
            async_writing: true
            client_count: 20
            io_buffer_size: 8192
        logging_flows:
          - name: flow_name
            inputs: [input_name]
            outputs: [output_name]

    Playbook は以下のパラメーターを使用します。

    logging_pki_files
    このパラメーターを使用して、TLS を設定し、ca_cert_srccert_src および private_key_src パラメーターを指定する必要があります。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    tls
    このパラメーターを使用すると、ネットワーク経由でログを安全に転送できるようになります。セキュアなラッパーが必要ない場合は、tls: true と設定できます。
  2. Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

16.7. RELP でのロギングシステムロールの使用

Reliable Event Logging Protocol (RELP) とは、TCP ネットワークを使用する、データとメッセージロギング用のネットワーキングプロトコルのことです。イベントメッセージを確実に配信するので、メッセージの損失が許されない環境で使用できます。

RELP の送信側はコマンド形式でログエントリーを転送し、受信側は処理後に確認応答します。RELP は、一貫性を保つために、転送されたコマンドごとにトランザクション番号を保存し、各種メッセージの復旧します。

RELP Client と RELP Server の間に、リモートロギングシステムを検討することができます。RELP Client はリモートロギングシステムにログを転送し、RELP Server はリモートロギングシステムから送信されたすべてのログを受け取ります。

管理者は Logging システムロールを使用して、ログエントリーが確実に送受信されるようにロギングシステムを設定することができます。

16.7.1. RELP を使用したクライアントロギングの設定

Logging システムロールを使用して、ローカルマシンにログインしている RHEL システムでロギングを設定し、Ansible Playbook を実行して、ログを RELP でリモートロギングシステムに転送できます。

この手順では、Ansible インベントリーの client グループ内の全ホストに RELP を設定します。RELP 設定は Transport Layer Security (TLS) を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • RELP を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying basic input and relp output
      hosts: clients
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: basic_input
            type: basics
        logging_outputs:
          - name: relp_client
            type: relp
            target: _logging.server.com_
            port: 20514
            tls: true
            ca_cert: _/etc/pki/tls/certs/ca.pem_
            cert: _/etc/pki/tls/certs/client-cert.pem_
            private_key: _/etc/pki/tls/private/client-key.pem_
            pki_authmode: name
            permitted_servers:
              - '*.server.example.com'
        logging_flows:
          - name: _example_flow_
            inputs: [basic_input]
            outputs: [relp_client]

    Playbook は、以下の設定を使用します。

    • target:リモートロギングシステムが稼働しているホスト名を指定する必須パラメーターです。
    • port: リモートロギングシステムがリッスンしているポート番号です。
    • tls:ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

      • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) を、コントロールノードから転送する管理対象ノードの宛先として使用します。この場合、ファイル名はトリプレットの元の名前と同じです。
      • {ca_certcertprivate_key} トリプレットが設定されている場合には、ファイルはロギング設定の前にデフォルトのパスを配置する必要があります。
      • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    • ca_cert:CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    • cert:証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    • private_key:秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    • ca_cert_src:ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert が指定している場合は、その場所にコピーされます。
    • cert_src:ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    • private_key_src:ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合には、その場所にコピーされます。
    • pki_authmode:name または fingerprint の認証モードを使用できます。
    • permitted_servers:ロギングクライアントが、TLS 経由での接続およびログ送信を許可するサーバーの一覧。
    • inputs:ロギング入力ディクショナリーの一覧。
    • outputs:ロギング出力ディクショナリーの一覧。
  2. オプション:Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

16.7.2. RELP を使用したサーバーログの設定

Logging システムロールを使用して、RHEL システムのログインをサーバーとして設定し、Ansible Playbook を実行して RELP でリモートロギングシステムからログを受信できます。

以下の手順では、Ansible インベントリーの server グループ内の全ホストに RELP を設定します。RELP 設定は TLS を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • RELP を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying remote input and remote_files output
      hosts: server
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: relp_server
            type: relp
            port: 20514
            tls: true
            ca_cert: _/etc/pki/tls/certs/ca.pem_
            cert: _/etc/pki/tls/certs/server-cert.pem_
            private_key: _/etc/pki/tls/private/server-key.pem_
            pki_authmode: name
            permitted_clients:
              - '_*example.client.com_'
        logging_outputs:
          - name: _remote_files_output_
            type: _remote_files_
        logging_flows:
          - name: _example_flow_
            inputs: _relp_server_
            outputs: _remote_files_output_

    Playbook は、以下の設定を使用します。

    • port: リモートロギングシステムがリッスンしているポート番号です。
    • tls:ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

      • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) を、コントロールノードから転送する管理対象ノードの宛先として使用します。この場合、ファイル名はトリプレットの元の名前と同じです。
      • {ca_certcertprivate_key} トリプレットが設定されている場合には、ファイルはロギング設定の前にデフォルトのパスを配置する必要があります。
      • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    • ca_cert:CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    • cert:証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    • private_key:秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    • ca_cert_src:ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert が指定している場合は、その場所にコピーされます。
    • cert_src:ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    • private_key_src:ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合には、その場所にコピーされます。
    • pki_authmode:name または fingerprint の認証モードを使用できます。
    • permitted_clients:ロギングサーバーが TLS 経由での接続およびログ送信を許可するクライアントの一覧。
    • inputs:ロギング入力ディクショナリーの一覧。
    • outputs:ロギング出力ディクショナリーの一覧。
  2. オプション:Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

16.8. 関連情報