コンピューターセキュリティーは、コンピューティングと情報処理の幅広い分野で使用される一般的な用語です。コンピューターシステムとネットワークを使用して日々の業務を行い、重要な情報へアクセスしている業界では、企業データを総体的資産の重要な部分であると見なしています。総保有コスト (Total Cost of Ownership: TCO) やサービスの品質 (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 をインストールする際に使用するインストールメディアは、特定のタイミングで作成されたスナップショットです。そのため、セキュリティー修正が最新のものではなく、このインストールメディアで設定するシステムが公開されてから修正された特定の問題に対して安全性に欠ける場合があります。

脆弱性が含まれる可能性のあるオペレーティングシステムをインストールする場合には、必ず、公開レベルを、必要最小限のネットワークゾーンに限定してください。最も安全な選択肢は、インストールプロセス中はマシンをネットワークから切断した状態にする「ネットワークなし」のゾーンです。インターネット接続からのリスクが最も高くなっていますが、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 140-2 モードを有効または無効にする fips-mode-setup ツールは、内部的に FIPS システム全体の暗号化ポリシーレベルを使用します。

手順

関連資料

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

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

関連資料

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 コマンドのすべてのサブコマンドは、以下のような詳細な組み込みヘルプを提供します。

$ 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 プロトコルで有効になります。

前提条件

手順

関連資料

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

前提条件

手順

前提条件

手順

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

前提条件

手順

AIDE の詳細は、以下のドキュメントを参照してください。

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

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

前提条件

手順

関連資料

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

前提条件

手順

暗号化したデバイス (この場合は /dev/sdb1) を、たとえば後でロックを解除できるように、取り外した LUKS ヘッダーもアクセスできるようにする必要があります。

# cryptsetup open --header /path/to/header /dev/sdb1 my_crypt_device

関連資料

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

図8.1 LUKS1 で暗号化したボリュームを使用する場合の NBDE スキーム (LUKS2 ボリュームには luksmeta パッケージが使用されていない)

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

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

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

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

クライアントおよびサーバーのコンポーネントはともに 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 アンロックを使用してディスクをアンロックできます。

Clevis のプラグイン可能なフレームワークとピンを、暗号化したボリュームを使用するマシン (クライアント) にインストールするには、root で以下のコマンドを実行します。

# yum install clevis

データを複号するには、clevis decrypt コマンドを実行して、JWE (JSON Web Encryption) フォーマットで暗号文を提供します。

$ clevis decrypt < secret.jwe

関連資料

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

# yum install tang

systemd を使用して、tangd サービスを有効にして開始します。

# systemctl enable tangd.socket --now
Created symlink from /etc/systemd/system/multi-user.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket.

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

鍵の手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。詳細は jose -h コマンドを実行するか、man ページの jose(1) を参照してください。

# DB=/var/db/tang
# jose jwk gen -i '{"alg":"ES512"}' -o $DB/new_sig.jwk
# jose jwk gen -i '{"alg":"ECMR"}' -o $DB/new_exc.jwk

# mv $DB/old_sig.jwk $DB/.old_sig.jwk
# mv $DB/old_exc.jwk $DB/.old_exc.jwk

Tang は、通信にポート 80 を使用します。このポートは Web サーバーにも広く使用されています。Tang のポート番号を変更するには、標準の systemd メカニズムを使用して tangd.socket ユニットファイルを上書きします。

以下の手順は、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

関連資料

# 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

関連資料

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

Clevis は、登録プロセスを完全に自動化するために、キックスタートと統合できます。

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

関連資料

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

LUKS で暗号化した非 root ボリュームをアンロックするのに NBDE を使用するには、以下の手順を行います。

関連資料

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

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

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

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

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

関連資料

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

自動登録可能な暗号化イメージをクラウド環境にデプロイすると、特有の課題が発生する可能性があります。上で詳述した他の仮想化環境と同様に、LUKS マスター鍵が共有されないように、イメージのインスタンス化は何度も行わないでください。したがって、lorax、virt-install などの自動デプロイメントシステムと Kickstart ファイルをともに使用して、イメージのビルドプロセス時にマスター鍵の一意性を保証する必要があります。

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

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

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

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

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

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

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

9.1.1. Audit システムのアーキテクチャー

Audit システムは、ユーザースペースアプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要パートで構成されます。カーネルコンポーネントは、ユーザースペースアプリケーションからシステムコールを受け、これを user、task、または exit のいずれかのフィルターで振り分けます。システムが exclude フィルターを通過すると、前述のフィルターの 1 つに送られます。このフィルターは Audit ルール設定に基づいて、システムコールを Audit デーモンに送信してさらに処理します。図9.1「Audit システムのアーキテクチャー」 にこのプロセスを示します。

図9.1 Audit システムのアーキテクチャー

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

• auditctl - Audit 制御ユーティリティーはカーネル Audit コンポーネントと対話し、ルールを管理するだけでなくイベント生成プロセスの多くの設定やパラメーターも制御します。
• 残りの Audit ユーティリティーは Audit ログファイルのコンテンツを入力として受け取り、ユーザーの要件に基づいて出力を生成します。たとえば、aureport ユーティリティーは記録された全イベントのレポートを生成します。

Audit dispatcher デーモン (audisp) 機能は、Audit デーモン (auditd) に統合されるようになりました。監査イベントと、リアルタイムの分析プログラムの対話のためのプラグイン設定ファイルは、デフォルトで /etc/audit/plugins.d/ ディレクトリーに保存されます。

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