コンピューターセキュリティーは、コンピューティングと情報処理の幅広い分野で使用される一般的な用語です。コンピューターシステムとネットワークを使用して日々の業務を行い、重要な情報へアクセスしている業界では、企業データを総体的資産の重要な部分であると見なしています。総保有コスト (Total Cost of Ownership: TCO)、投資利益率 (Return on Investment: ROI)、サービスの品質 (Quality of Service: QoS) などの用語や評価指標は日常的なビジネス用語として用いられるようになっています。各種の業界が、計画およびプロセス管理コストの一環として、これらの評価指標を用いてデータ保全性や可用性などを算出しています。電子商取引などの業界では、データの可用性と信頼性は、成功と失敗の違いを意味します。

企業はどの業界でも、米国医師会 (AMA: American Medical Association)、米国電気電子学会 (IEEE: Institute of Electrical and Electronics Engineers) などの標準化推進団体が作成する規制やルールに従っています。情報セキュリティーにも同じことが言えます。多くのセキュリティーコンサルタントやベンダーが 機密性 (Confidentiality)、保全性 (Integrity)、可用性 (Availability) の頭文字をとった CIA として知られる標準セキュリティーモデルを採用しています。この 3 階層モデルは、機密情報のリスク評価やセキュリティー方針の確立において、一般的に採用されているモデルです。以下でこの CIA モデルを説明します。

Red Hat Enterprise Linux は、業界のベストプラクティスに従い、FIPS 140-2、Common Criteria (CC) などのセキュリティー認証を受けています。

ナレッジベースの記事「RHEL 8 core crypto components」では、Red Hat Enterprise Linux 8 コア暗号化コンポーネントの概要 (「どのコンポーネントか選択されているか」、「どのように選択されているか」、「オペレーティングシステムにどのように統合されているかどうか」、「ハードウェアセキュリティーモジュールおよびスマートカードにどのように対応しているか」、および「暗号化認証がどのように適用されているか」) を説明します。

多くの場合、コンピューターセキュリティーは、一般に コントロール と呼ばれる以下の 3 つのマスターカテゴリーに分類されます。

この 3 つのカテゴリーは、セキュリティーの適切な実施における主な目的を定義するものです。このコントロールには、コントロールと、その実装方法を詳細化するサブカテゴリーがあります。

時間やリソースがあり、その気になれば、攻撃者はほとんどすべてのシステムに侵入できます。現在利用できるセキュリティーの手順と技術をすべて駆使しても、すべてのシステムを侵入から完全に保護できる訳ではありません。ルーターは、インターネットへのセキュアなゲートウェイを提供します。ファイアウォールは、ネットワークの境界を保護します。仮想プライベートネットワーク (VPN) では、データが、暗号化されているストリームで安全に通過できます。侵入検知システムは、悪意のある活動を警告します。しかし、これらの技術が成功するかどうかは、以下のような数多くの要因によって決まります。

データシステムと各種技術が動的であることを考えると、企業リソースを保護するタスクは極めて複雑になる可能性もあります。この複雑さゆえに、使用するすべてのシステムの専門家を見つけることは、多くの場合困難になります。情報セキュリティーの多くの分野によく精通している人材を確保することはできても、多くの分野を専門とするスタッフを確保することは容易ではありません。これは、情報セキュリティーの各専門分野で、継続的な注意と重点が必要となるためです。情報セキュリティーは、常に変化しています。

脆弱性アセスメントは、お使いのネットワークとシステムのセキュリティーに関する内部監査です。このアセスメントの結果により、ネットワークの機密性、完全性、および可用性の状態が明らかになります。通常、脆弱性アセスメントは、対象システムとリソースに関する重要なデータを収集する調査フェーズから開始します。その後システム準備フェーズとなります。基本的にこのフェーズでは、対象を絞り、すべての既知の脆弱性を調べます。準備フェーズが終わると報告フェーズになります。ここでは、調査結果が高中低のカテゴリーに分類され、対象のセキュリティーを向上させる (または脆弱性のリスクを軽減する) 方法が話し合われます。

たとえば、自宅の脆弱性アセスメントを実施することを想定してみましょう。まずは自宅のドアを点検し、各ドアが閉まっていて、かつ施錠されていることを確認します。また、すべての窓が完全に閉まっていて鍵が閉まっていることも確認します。これと同じ概念が、システム、ネットワーク、および電子データにも適用されます。悪意のあるユーザーはデータを盗んで、破壊します。悪意のあるユーザーが使用するツール、思考、動機に注目すると、彼らの行動にすばやく反応することが可能になります。

表1.1「一般的な不正使用」では、侵入者が組織のネットワークリソースにアクセスするために使用する最も一般的な不正使用とエントリーポイントの例を挙げて詳しく説明します。この一般的な不正使用では、それがどのように実行され、管理者がその攻撃からネットワークをどのように適切に保護できるかを理解していることが重要になります。

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

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

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

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

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

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

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

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

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

Red Hat Enterprise Linux 8 には、以下のポリシーレベルが含まれます。

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

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

$ update-crypto-policies --show
DEFAULT

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

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

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

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

すべてのポリシーレベルで無効になっている暗号スイートおよびプロトコル

以下の暗号スイートおよびプロトコルは、すべての暗号化ポリシーレベルで無効になっています。これは、各アプリケーションで明示的に有効にした場合に限り利用可能にできます。

暗号ポリシーレベルで有効な暗号スイートおよびプロトコル

次の表は、暗号ポリシーの各レベルで有効な暗号化スイートおよびプロトコルを示しています。

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

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

コンテナー内の連邦情報処理規格 (FIPS) 140-2 の要件に従って暗号モジュールの自己チェックを有効にするには、以下を行います。

前提条件

手順

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

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

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

# curl https://example.com --ciphers DES-CBC3-SHA:RSA-DES-CBC3-SHA

include /etc/crypto-policies/back-ends/libreswan.config

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

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

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

Red Hat Enterprise Linux 8 では、デフォルトでスマートカード用に OpenSC PKCS #11 ドライバーが提供されています。ただし、Red Hat Enterprise Linux では、ハードウェアトークンと HSM に独自の PKCS #11 モジュールがあります。この PKCS #11 モジュールは p11-kit ツールで登録できます。これは、システムの登録済みスマートカードドライバーにおけるラッパーとして機能します。

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

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

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

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

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

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

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

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 を参照してください。

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 プレフィックスがエンジン名を参照するためです。

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

詳細は、man ページの p11-kit (8) を参照してください。

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

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

$ trust list --help
usage: trust list --filter=<what>

  --filter=<what>     filter of what to export
                        ca-anchors        certificate anchors
                        blacklist         blacklisted certificates
                        trust-policy      anchors and blacklist (default)
                        certificates      all certificates
                        pkcs11:object=xx  a PKCS#11 URI
  --purpose=<usage>   limit to certificates usable for the purpose
                        server-auth       for authenticating servers
                        client-auth       for authenticating clients
                        email             for email protection
                        code-signing      for authenticating signed code
                        1.2.3.4.5...      an arbitrary object id
  -v, --verbose       show verbose debug output
  -q, --quiet         suppress command output

詳細は、以下の man ページを参照してください。

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

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

Red Hat Enterprise Linux のセキュリティー監査機能は、標準規格「セキュリティー設定共通化手順 (Security Content Automation Protocol (SCAP))」を基にしています。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 パッチ定義を作成してサポートし、マシンが判読可能なセキュリティーアドバイザリーを提供します。

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

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

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

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

OpenSCAP スキャナーで、リモートシステムの脆弱性も確認できます。この機能は、oscap-ssh ツールにより SSH プロトコルで有効になります。

RHEL 8 は、セキュリティーポリシーを扱う複数のプロファイルを提供します。スキャンまたは修復にそれらを使用することを決定する前に、その一覧を表示して oscap info サブコマンドで詳しい説明を確認できます。

SCAP セキュリティーガイド スイートは、XCCDF、OVAL、およびデータストリームのドキュメント形式で、複数のプラットフォームのプロファイルを提供します。この プロファイル は、OSPP (Operating System Protection Profile)、PCI-DSS (Payment Card Industry Data Security Standard) などのセキュリティーポリシーに基づく一連のルールです。これにより、セキュリティー規格に関しては、自動化された方法でシステムを監査できます。

この手順を使用して、OSPP (Protection Profile for General Purpose Operating Systems) に合わせて RHEL 8 システムを修復します。

この手順に従い、SCAP セキュリティガイド プロジェクトの Ansible Playbook ファイルを使用して、OSPP (Protection Profile for General Purpose Operating Systems) に合わせてシステムを修復します。

この手順に従って、システムを OSPP (Protection Profile for General Purpose Operating Systems) に合わせる修正を含む Ansible Playbook を作成します。次の手順では、システムに変更を加えることなく、後のアプリケーション用にファイルを準備する方法を説明します。

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

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

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

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

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

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

以下の手順には、暗号化されていないデバイスのデータを LUKS2 形式で暗号化する手順が含まれます。

以下の手順では、LUKS ヘッダーを保存する空き領域を作成せずにファイルシステムを暗号化する方法を説明します。ヘッダーは、追加のセキュリティー層としても使用できる、独立した場所に保存されます。

この手順では、LUKS2 暗号化形式を使用します。

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

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

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) は、Red Hat Enterprise Linux 8 のデフォルト形式であるため、NBDE のプロビジョニング状態は、LUKS2 ヘッダーにトークンとして保存されます。luksmeta パッケージによる NBDE のプロビジョニング状態は、LUKS1 で暗号化したボリュームにのみ使用されます。Tang 用の Clevis ピンは、規格を必要とせずに LUKS1 と LUKS2 の両方をサポートします。

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

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

/tmp ディレクトリー、/var ディレクトリー、/usr/local/ ディレクトリーなどを使用したものを含む、ネットワーク接続が確立される前に起動するように要求するファイルシステムが含まれるすべての LUKS 暗号化デバイスは、root ボリューム とみなされます。また、ネットワークが起動する前に実行するサービスが使用するすべてのマウントポイント (/var/log/、var/log/audit/、/opt など) は、ルートデバイスに切り替えてから早めにマウントすることが必要になります。/etc/fstab ファイルに _netdev オプションを使用せずに、root ボリュームを特定できます。

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

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

次の手順に従って、Tang 鍵を変更します。鍵を変更するのに適した間隔は、アプリケーション、鍵サイズ、および組織のポリシーにより異なります。

以下の手順は、Tang ネットワークサーバーを使用して、暗号化したボリュームの自動ロック解除を設定する手順を説明します。

以下の手順は、Trusted Platform Module 2.0 (TPM 2.0) ポリシーを使用して、暗号化したボリュームの自動ロック解除を設定する手順を説明します。

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

たとえば、SHA-1 バンクに対して、インデックス 0 および 1 の PCR にデータをシールするには、以下を行います。

$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < input-plain.txt > secret.jwe

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

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

# 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:192.0.2.45"

# dracut -fv --regenerate-all

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

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

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

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

システムの起動時に LUKS で暗号化された非 root ボリュームのロックを解除するように NBDE を設定するには、次の手順を行います。

clevis luks bind コマンドは、LUKS マスター鍵を変更しません。これは、仮想マシンまたはクラウド環境で使用する、LUKS で暗号化したイメージを作成する場合に、このイメージを実行するすべてのインスタンスがマスター鍵を共有することを意味します。これにはセキュリティーの観点で大きな問題があるため、常に回避する必要があります。

これは、Clevis の制限ではなく、LUKS の設計原理です。クラウドに暗号化された root ボリュームが必要な場合は、クラウドの Red Hat Enterprise Linux の各インスタンスにインストールプロセスを実行できるようにする (通常はキックスタートを使用) 必要があります。このイメージは、LUKS マスター鍵を共有しなければ共有できません。

仮想化環境に自動アンロックをデプロイする場合は、キックスタートファイルを使用して lorax、virt-install などのシステムを使用すること (「キックスタートを使用して、LUKS で暗号化した root ボリュームの自動登録の設定」を参照)、または暗号化した各仮想マシンに固有のマスター鍵があるようにする自動プロビジョニングツールを使用することを Red Hat は強く推奨します。

TPM 2.0 ポリシーを使用した自動ロック解除は、仮想マシンではサポートされていないことに注意してください。

自動登録可能な暗号化イメージをクラウド環境にデプロイすると、特有の課題が発生する可能性があります。他の仮想化環境と同様に、LUKS マスター鍵を共有しないように、1 つのイメージから起動するインスタンス数を減らすことが推奨されます。

したがって、ベストプラクティスは、どのパブリックリポジトリーでも共有されず、限られたインスタンスのデプロイメントのベースを提供するように、イメージをカスタマイズすることです。作成するインスタンスの数は、デプロイメントのセキュリティーポリシーで定義する必要があります。また、LUKS マスター鍵の攻撃ベクトルに関連するリスク許容度に基づいて決定する必要があります。

LUKS に対応する自動デプロイメントを構築するには、Lorax、virt-install などのシステムとキックスタートファイルを一緒に使用し、イメージ構築プロセス中にマスター鍵の一意性を確保する必要があります。

クラウド環境では、ここで検討する 2 つの Tang サーバーデプロイメントオプションが利用できます。まず、クラウド環境そのものに Tang サーバーをデプロイできます。もしくは、2 つのインフラストラクチャー間で VPN リンクを使用した独立したインフラストラクチャーで、クラウドの外に Tang サーバーをデプロイできます。

クラウドに Tang をネイティブにデプロイすると、簡単にデプロイできます。ただし、別のシステムの暗号文のデータ永続化層でインフラストラクチャーを共有します。Tang サーバーの秘密鍵および Clevis メタデータは、同じ物理ディスクに保存できる場合があります。この物理ディスクでは、暗号文データへのいかなる不正アクセスが可能になります。

Linux の Audit システムは、システムのセキュリティー関連情報を追跡する方法を提供します。事前設定されたルールに基づき、Audit は、ログエントリーを生成し、システムで発生しているイベントに関する情報をできるだけ多く記録します。この情報は、ミッションクリティカルな環境でセキュリティーポリシーの違反者と、違反者によるアクションを判断する上で必須のものです。

以下は、Audit がログファイルに記録できる情報の概要です。

Audit システムの使用は、多くのセキュリティー関連の認定における要件でもあります。Audit は、以下の認定またはコンプライアンスガイドの要件に合致するか、それを超えるように設計されています。

Audit は以下でも認定されています。

Audit システムは、ユーザー空間アプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要部分で構成されます。カーネルコンポーネントは、ユーザー空間アプリケーションからシステムコールを受け、これを user、task、fstype、または exit のいずれかのフィルターで振り分けます。

システムコールが exclude フィルターを通過すると、前述のフィルターのいずれかに送られます。このフィルターにより、Audit ルール設定に基づいてシステムコールが Audit デーモンに送信され、さらに処理されます。

ユーザー空間の Audit デーモンは、カーネルから情報を収集し、ログファイルのエントリーを作成します。他のユーザー空間ユーティリティーは、Audit デーモン、カーネルの Audit コンポーネント、または Audit ログファイルと相互作用します。

RHEL 8 では、Audit dispatcher デーモン (audisp) 機能は、Audit デーモン (auditd) に統合されています。監査イベントと、リアルタイムの分析プログラムの相互作用に使用されるプラグイン設定ファイルは、デフォルトで /etc/audit/plugins.d/ ディレクトリーに保存されます。

デフォルトの auditd 設定は、ほとんどの環境に適しています。ただし、厳格なセキュリティーポリシーに対応する必要がある場合は、/etc/audit/auditd.conf ファイルの Audit デーモン設定に以下の設定が推奨されます。

残りの設定オプションは、ローカルのセキュリティーポリシーに合わせて設定します。

auditd が設定されたら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。root ユーザーで次のコマンドを実行し、auditd を起動します。

~]# service auditd start

システムの起動時に auditd が開始するように設定するには、次のコマンドを実行します。

~]# systemctl enable auditd

service auditd action コマンドを使用すると、auditd でさまざまなアクションを実行できます。ここでの アクション は以下のいずれかになります。

デフォルトでは、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) が複数使用されています。上記のイベントの詳細な分析は以下のようになります。

Audit システムは、ログファイルで取得するものを定義する一連のルールで動作します。Audit ルールは、auditctl ユーティリティーを使用してコマンドラインで設定するか、/etc/audit/rules.d/ ディレクトリーで設定できます。

auditctl コマンドを使用すると、Audit システムの基本的な機能を制御し、どの Audit イベントをログに記録するかを指定するルールを定義できます。

# auditctl -F exe=/bin/id -S execve -k execution_bin_id

再起動後も持続するように 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/doc/audit/rules/30-stig.rules

/usr/share/doc/audit/rules/ ディレクトリーには、audit パッケージが各種の証明書規格に従って、事前設定ルールのファイル一式が提供されています。

上記の設定ファイルを使用するには、/etc/audit/rules.d/ ディレクトリーにコピーして、以下のように augenrules --load コマンドを使用します。

# cp /usr/share/doc/audit/rules/10-base-config.rules /usr/share/doc/audit/rules/30-stig.rules /usr/share/doc/audit/rules/31-privileged.rules /usr/share/doc/audit/rules/99-finalize.rules /etc/audit/rules.d/
# augenrules --load

詳細、トラブルシューティング、およびその他の使用例は、man ページの audit.rules(7) を参照してください。

augenrules スクリプトは、/etc/audit/rules.d/ ディレクトリーにあるルールを読み込み、audit.rules ファイルにコンパイルします。このスクリプトは、自然なソート順序の特定の順番で、.rules で終わるすべてのファイルを処理します。このディレクトリーのファイルは、以下の意味を持つグループに分類されます。

ルールは、すべてを一度に使用することは意図されていません。ルールは考慮すべきポリシーの一部であり、個々のファイルは /etc/audit/rules.d/ にコピーされます。たとえば、STIG 設定でシステムを設定し、10-base-config、30-stig、31-privileged、99-finalize の各ルールをコピーします。

/etc/audit/rules.d/ ディレクトリーにルールを置いたら、--load ディレクティブで augenrules スクリプトを実行することでそれを読み込みます。

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
[trimmed for clarity]

Audit システムの詳細は、以下の資料を参照してください。

fapolicyd ソフトウェアフレームワークは、ユーザー定義ポリシーに基づいたアプリケーションのホワイトリスト化およびブラックリスト化の形式を導入しました。アプリケーションのホワイトリスト機能では、システム上で信頼されていないアプリケーションや悪意のあるアプリケーションを実行しないようにするための最も効率的な方法を利用できます。

fapolicyd フレームワークは、以下のコンテンツを提供します。

管理者は、パス、ハッシュ、MIME タイプ、信頼に基づいて、すべてのアプリケーションに実行ルール allow および deny の両方を監査する定義できます。

アプリケーションのホワイトリストには、信頼の概念が導入されています。アプリケーションは、システムパッケージマネージャーによって適切にインストールされると信頼されるため、システムの RPM データベースに登録されます。fapolicyd デーモンは、RPM データベースを信頼できるバイナリーとスクリプトの一覧として使用します。fapolicyd YUM プラグインは、YUM パッケージマネージャーにより処理されるシステム更新をすべて登録します。プラグインは、このデータベースの変更を fapolicyd デーモンに通知します。

rpm ユーティリティーを使用したインストールでは、データベースを手動で更新する必要があり、アプリケーションを追加する他の方法では、カスタムルールを作成し、fapolicyd サービスを再起動する必要があります。

fapolicyd サービス構成は、次の構造を持つ /etc/fapolicyd/ ディレクトリーにあります。

RHEL に fapolicyd フレームワークをデプロイするには、以下を行います。

fapolicyd パッケージのデフォルトのルールセットは、システム機能に影響しません。バイナリーとスクリプトを非標準のディレクトリーに保存したり、yum インストーラーまたは rpm インストーラーなしでアプリケーションを追加したりするようなカスタムシナリオの場合は、既存のルールを変更するか、新しいルールを追加する必要があります。次の手順は、新しいルールを追加してカスタムバイナリーをホワイトリストに追加する方法を示しています。

次のセクションでは、fapolicyd アプリケーションホワイトリストフレームワークの基本的なトラブルシューティングのヒントと、rpm コマンドを使用してアプリケーションを追加するためのガイダンスを示します。