著者はhttps://www.brightfunds.org/funds/foss-nonprofits [無料およびオープンソース基金]を選択して、https://do.co/w4do-cta [Donationsのために書く]の一部として寄付を受け取りましたプログラム。

前書き

https://www.inspec.io [InSpec]は、システムをテストおよび監査して、統合、セキュリティ、およびその他のポリシー要件の遵守を確認するための、オープンソースの自動テストフレームワークです。 開発者は、InSpecコードを使用して、インフラストラクチャとアプリケーションの実際の状態をターゲット状態に対してテストできます。

テストするポリシー要件を指定するために、InSpectionには監査コントロールが含まれています。 従来、開発者はポリシー要件を手動で適用し、多くの場合、実稼働環境に変更を展開する直前にこれを行います。 ただし、InSpecを使用すると、開発者は製品開発のすべての段階でコンプライアンスを継続的に評価できるため、開発プロセスの初期段階で問題を解決できます。 InSpec DSL(ドメイン固有言語)は、Rubyで作成されたDSLテストツールであるhttp://rspec.info/[RSpec]上に構築され、構文を指定します。監査コントロールの作成に使用されます。

InSpecには、https://www.inspec.io/docs/reference/resources [resources]のコレクションも含まれており、システムの特定の部分の構成を支援し、監査制御の作成を簡素化します。 使用できない特定のソリューションを定義する必要がある場合、独自のカスタムリソースを作成する機能があります。 Universal matchersを使用すると、すべてのInSpecテストでリソース値を期待値と比較できます。

このチュートリアルでは、Ubuntu 18.04を実行しているサーバーにInSpecをインストールします。 サーバーのオペレーティングシステムファミリを検証するテストを作成することから始めます。次に、ゼロからPostgreSQL監査プロファイルを作成します。 この監査プロファイルは、サーバーにPostgreSQLがインストールされていること、およびそのサービスが実行されていることを確認することから始まります。 次に、テストを追加して、PostgreSQLサービスが正しいポート、アドレス、プロトコル、およびユーザーで実行されていることを確認します。 次に、特定のPostgreSQL構成パラメーターをテストし、最後にクライアント認証構成を監査します。

前提条件

このチュートリアルを実行する前に、次のものが必要です。

  • sudo non -rootユーザーとファイアウォール。

  • このhttps://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-18-04 [インストールガイド]に従って動作するPostgreSQL 10インストール。

ステップ1-環境の準備

この手順では、InSpecの最新の安定バージョンをダウンロードしてホームディレクトリに解凍します。 InSpecは、https://downloads.chef.io/inspec [downloads]ページでインストール可能なバイナリを提供します。

ホームディレクトリに移動します。

cd ~

次に、 `+ curl +`でバイナリをダウンロードします。

curl -LO https://packages.chef.io/files/stable/inspec/3.7.11-1<^>_amd64.deb

次に、 `+ sha256sum +`コマンドを使用して、ダウンロードしたファイルのチェックサムを生成します。 これは、ダウンロードしたファイルの整合性と信頼性を検証するためです。

sha256sum

各バイナリのチェックサムはhttps://downloads.chef.io/inspec[InSpecダウンロードページ]にリストされているため、ダウンロードページにアクセスして、このコマンドの出力と比較してください。

Output inspec_3.7.11-1_amd64.deb

チェックサムが異なる場合は、ダウンロードしたファイルを削除して、ダウンロードプロセスを繰り返します。

次に、ダウンロードしたバイナリをインストールします。 これには、パッケージ管理に使用できる `+ dpkg `コマンドを使用します。これは、デフォルトでUbuntuなどのすべてのDebianベースのシステムに付属しています。 ` -i +`フラグは、パッケージファイルをインストールするようにdpkgコマンドにプロンプ​​トを出します。

sudo dpkg -i

エラーがない場合は、InSpecが正常にインストールされたことを意味します。 インストールを確認するには、次のコマンドを入力します。

inspec version

インストールしたInSpecのバージョンを示す出力が表示されます。

Output

バージョン番号が表示されない場合は、手順1をもう一度実行します。

この後、パッケージをインストールしたときに不要になったため、「++」を削除できます。

rm

サーバーにInSpecが正常にインストールされました。 次のステップでは、サーバーのオペレーティングシステムファミリを検証するテストを作成します。

ステップ2-最初のInSpecテストの完了

この手順では、オペレーティングシステムファミリが `+ debian +`であることをテストする最初のInSpecテストを完了します。

https://www.inspec.io/docs/reference/resources/os/ [+ os +]リソースを使用します。これは組み込みのInSpec監査リソースであり、システムが実行されているプラ​​ットフォームをテストします。 また、「+ eq 」マッチャーも使用します。 ` eq +`マッチャーは、2つの値の正確な等価性をテストする汎用マッチャーです。

InSpecテストは、リソースの機能の1つを検証する1つ以上の「+ it」および「+ its」ステートメントを含む「+ describe」ブロックで構成されます。 各ステートメントは、システムの特定の状態の予想を_assertions_として記述します。 アサーションを作成するために含めることができる2つのキーワードは、「+ should 」と「 should_not +」で、それぞれ条件がtrueとfalseであることをアサートします。

`+ os_family.rb +`というファイルを作成してテストを保持し、テキストエディターで開きます。

nano

以下をファイルに追加します。

os_family.rb

describe os.family do
 it {should eq 'debian'}
end

このテストは、ターゲットシステムのオペレーティングシステムファミリが + debian`であることを確認します。 その他の可能な値は、「+ windows or」、「+ unix」、「+ bsd」などです。 完全なリストはhttps://www.inspec.io/docs/reference/resources/os/ [+ os +`リソースドキュメント]にあります。 ファイルを保存して終了します。

次に、次のコマンドでテストを実行します。

inspec exec

テストに合格すると、次のような出力が表示されます。

OutputProfile: tests from os_family.rb (tests from os_family.rb)
Version: (not specified)
Target:  local://

 debian
    ✔  should eq "debian"

Test Summary: 1 successful, 0 failures, 0 skipped

出力では、 `+ Profile `には実行したばかりのプロファイルの名前が含まれています。 このテストはプロファイルに含まれていないため、InSpecはテストのファイル名 ` tests from os_family.rb `からデフォルトのプロファイル名を生成します。 (次のセクションでInSpec _profiles_を使用して、PostgreSQL InSpecプロファイルの作成を開始します。)ここでは、InSpecは、プロファイルでのみバージョンを指定できるため、 ` Version `を ` not specified +`として表示します。

`+ Target `フィールドは、テストが実行されるターゲットシステムを指定します。これは、ローカルまたは ` ssh `を介したリモートシステムです。 この場合、ターゲットが ` local:// +`を示すように、ローカルシステムでテストを実行しました。

便利なことに、出力には、実行されたテストの左側にチェックマーク記号(✔)が表示され、テストが成功したことが示されます。 テストに失敗すると、出力に十字記号(✘)が表示されます。

最後に、テストの概要には、成功、失敗、およびスキップされたテストの数に関する全体的な詳細が示されます。 この例では、1つのテストが成功しました。

これで、失敗したテストの出力がどのように見えるかがわかります。 `++`を開きます:

nano

この手順の前半で作成したテストでは、オペレーティングシステムファミリの期待値を「+ debian 」から「 windows +」に変更します。 この後のファイルの内容は次のとおりです。

os_family.rb

describe os.family do
 it {should eq ''}
end

ファイルを保存して終了します。

次に、次のコマンドで更新されたテストを実行します。

inspec exec

次のような出力が得られます。

OutputProfile: tests from os_family.fail.rb (tests from os_family.fail.rb)
Version: (not specified)
Target:  local://

 debian
    (✘)  should eq "windows"

    expected: "windows"
         got: "debian"

    (compared using ==)


Test Summary: 0 successful, 1 failure, 0 skipped

予想どおり、テストは失敗しました。 出力は、期待される( + windows +)値と実際の( + debian +)値が `+ os.family `プロパティに一致しないことを示しています。 `(compared using ==)`の出力は、 ` eq +`マッチャーがこの結果を得るために2つの値の文字列比較を実行したことを示しています。

この手順では、サーバーのオペレーティングシステムファミリを検証する成功したテストを作成しました。 また、失敗したテストのInSpec出力がどのようになるかを確認するために、失敗したテストを作成しました。 次のステップでは、PostgreSQLインストールをテストするための監査プロファイルの構築を開始します。

ステップ3-PostgreSQLインストールの監査

次に、PostgreSQLインストールを監査します。 まず、PostgreSQLがインストールされており、そのサービスが正しく実行されていることを確認します。 最後に、PostgreSQLシステムのポートとプロセスを監査します。 PostgreSQL監査では、すべてが「+」という名前のInSpec ` profile`内にさまざまなInSpecコントロールを作成します。

InSpec _control_は、関連するテストの高レベルのグループ化です。 コントロール内では、複数の `+ describe +`ブロックと、影響レベル、タイトル、説明、タグなどのテストを説明するメタデータを持つことができます。 InSpecプロファイルは、依存関係の管理とコードの再利用をサポートするためにコントロールを編成し、どちらもテストの複雑さの管理に役立ちます。 また、https://supermarket.chef.io/ [Chef Supermarket]を介してテストをパッケージ化し、一般の人々と共有するのにも役立ちます。 プロファイルを使用して、通常のRubyクラスとして実装するカスタムリソースを定義できます。

InSpecプロファイルを作成するには、 `+ init `コマンドを使用します。 次のコマンドを入力して、「+」プロファイルを作成します。

inspec init profile

これにより、プロファイルと同じ名前(この場合は++)で新しいディレクトリにプロファイルが作成されます。 次に、新しいディレクトリに移動します。

cd /

ディレクトリ構造は次のようになります。

/
├── controls
│   └── example.rb
├── inspec.yml
├── libraries
└── README.md

`+ controls / example.rb `ファイルには、ターゲットシステムに ` / tmp +`フォルダーが存在するかどうかをテストするサンプルコントロールが含まれています。 これはサンプルとしてのみ存在し、独自のテストに置き換えます。

最初のテストは、システムにパッケージ `+`がインストールされていること、および ` postgresql +`サービスがインストール、有効化、実行されていることを確認することです。

`+ controls / example.rb `ファイルの名前を ` controls / postgresql.rb +`に変更します。

mv controls/example.rb controls/postgresql.rb

次に、テキストエディターでファイルを開きます。

nano controls/postgresql.rb

ファイルの内容を次のものに置き換えます。

controls / postgresql.rb

control '1-audit_installation' do
 impact 1.0
 title 'Audit PostgreSQL Installation'
 desc 'Postgres should be installed and running'

 describe package('postgresql-10') do
   it {should be_installed}
   its('version') {should cmp >= '10'}
 end

 describe service('[email protected]') do
   it {should be_enabled}
   it {should be_installed}
   it {should be_running}
 end
end

前のコードブロックでは、名前とメタデータを使用してコントロールを定義することから始めます。

最初の + describe`ブロックでは、 + package`リソースを使用し、PostgreSQLパッケージ名 `+`をリソース引数として渡します。 ` package `リソースは、指定されたパッケージがシステムにインストールされていることをテストするためのマッチャー ` be_installed `を提供します。 パッケージがインストールされている場合は* true *を返し、そうでない場合は* false *を返します。 次に、 ` its `ステートメントを使用して、インストールされたPostgreSQLパッケージのバージョンが10以上であることを検証しました。 パッケージバージョンの文字列には通常、数値バージョン以外の他の属性が含まれているため、「 eq 」ではなく「 cmp 」を使用しています。 ` eq `は、完全に一致する場合にのみ* true *を返しますが、 ` cmp +`は制限が少なくなります。

2番目の「+ describe」ブロックでは、「+ service」リソースを使用し、PostgreSQL 10サービス名「+」をリソース引数として渡します。 ` service `リソースは、マッチャー ` be_enabled `、 ` be_installed `、および ` be_running +`を提供し、それぞれターゲットシステムに名前付きサービスがインストール、有効化、実行されている場合、* true *を返します。

ファイルを保存して終了します。

次に、プロファイルを実行します。 次のコマンドを実行する前に、 `++`ディレクトリにいることを確認してください。

inspec exec .

PostgreSQL前提条件チュートリアルを完了したため、テストに合格します。 出力は次のようになります。

OutputProfile: InSpec Profile (PostgreSQL)
Version: 0.1.0
Target:  local://

 ✔  1-audit_installation: Audit PostgreSQL Installation
    ✔  System Package postgresql-10 should be installed
    ✔  System Package postgresql-10 version should cmp >= "10"
    ✔  Service [email protected] should be enabled
    ✔  Service [email protected] should be installed
    ✔  Service [email protected] should be running


Profile Summary: 1 successful control, 0 control failures, 0 controls skipped
Test Summary: 5 successful, 0 failures, 0 skipped

出力は、制御が成功したことを示しています。 コントロールは、その中のすべてのテストが成功した場合にのみ成功します。 出力は、すべてのテストが成功したことも確認します。

PostgreSQLの正しいバージョンがインストールされ、サービスが正常であることを確認したら、PostgreSQLが正しいポート、アドレス、およびプロトコルでリッスンすることを保証する新しいコントロールを作成します。

このテストでは、_attributes_も使用します。 InSpec属性を使用してプロファイルをパラメーター化し、さまざまな環境またはターゲットシステムで簡単に再利用できるようにします。 `+ PORT +`属性を定義します。

テキストエディターで `+ inspec.yml +`ファイルを開きます:

nano inspec.yml

ファイルの最後に `+ port +`属性を追加します。 ファイルの最後に次を追加します。

inspec.yml

...
attributes:
 - name: port
   type: string
   default: '5432'

前のコードブロックでは、 `+ port `属性を追加し、デフォルト値の ` 5432 +`に設定しました。これは、PostgreSQLがデフォルトでリッスンするポートであるためです。

ファイルを保存して終了します。 次に、 `+ inspec.yml `を編集したばかりなので、 ` inspec check +`を実行して、プロファイルがまだ有効であることを確認します。

inspec check .

エラーがなければ、続行できます。 それ以外の場合は、 `+ inspec.yml +`ファイルを開き、ファイルの最後に属性が存在することを確認します。

次に、PostgreSQLプロセスが実行され、正しいユーザーで構成されていることを確認するコントロールを作成します。 テキストエディタで `+ controls / postgresql.rb +`を開きます。

nano controls/postgresql.rb

現在のテストファイル `+ controls / postgresql.rb +`の最後に次のコントロールを追加します。

controls / postgresql.rb

...
PORT = attribute('port')

control '2-audit_address_port' do
 impact 1.0
 title 'Audit Process and Port'
 desc 'Postgres port should be listening and the process should be running'

 describe port(PORT) do
   it {should be_listening}
   its('addresses') {should include '127.0.0.1'}
   its('protocols') {should cmp 'tcp'}
 end

 describe processes('postgres') do
   it {should exist}
   its('users') {should include 'postgres'}
 end

 describe user('postgres') do
   it {should exist}
 end
end

ここでは、 `+ port `プロファイル属性の値を保持するために ` PORT +`変数を宣言することから始めます。 次に、コントロールとそのメタデータを宣言します。

最初の + describe +`ブロックには、https://www.inspec.io/docs/reference/resources/port/ [+ port `]リソースを含めて、基本的なポートプロパティをテストします。 ` port `リソースは、マッチャー ` be_listening `、 ` addresses `、および ` protocols `を提供します。 ` be_listening `マッチャーを使用して、指定されたポートがターゲットシステムでリッスンしていることをテストします。 ポート ` 5432 `がリッスンしている場合は* true *を返し、そうでない場合は* false *を返します。 ` addresses `マッチャーは、指定されたアドレスがポートに関連付けられているかどうかをテストします。 この場合、PostgreSQLはローカルアドレス「+127.0.0.1」でリッスンします。 + + protocols +`マッチャーは、ポートがリッスンしているインターネットプロトコルをテストします。これは、 `+ icmp ++ tcp + / + tcp6 +、または + udp + / `+ udp6 `です。 PostgreSQLは ` tcp +`接続をリッスンします。

2番目の + describe +`ブロックには、https://www.inspec.io/docs/reference/resources/processes/ [+ processes `]リソースを含めます。 システムで実行されているプログラムのプロパティをテストするには、 ` processes `リソースを使用します。 まず、システムに ` postgres `プロセスが存在することを確認してから、 ` users `マッチャーを使用して、 ` postgres `ユーザーが ` postgres +`プロセスを所有していることをテストします。

3番目の + describe +`ブロックには、https://www.inspec.io/docs/reference/resources/user/ [+ user `]リソースがあります。 ユーザーが存在するかどうか、ユーザーが属するグループなど、ユーザーのユーザープロパティをテストするには、 ` user `リソースを含めます。 このリソースを使用して、 ` postgres `ユーザーがシステムに存在することをテストします。 保存して、 ` controls / postgresql.rb +`を終了します。

次に、次のコマンドを使用してプロファイルを実行します。

inspec exec .

テストに合格し、出力は次のようになります。

OutputProfile: InSpec Profile (PostgreSQL)
Version: 0.1.0
Target:  local://

 ✔  1-audit_installation: Audit PostgreSQL Installation
    ✔  System Package postgresql-10 should be installed
    ✔  System Package postgresql-10 version should cmp >= "10"
    ✔  Service [email protected] should be enabled
    ✔  Service [email protected] should be installed
    ✔  Service [email protected] should be running
 ✔  2-audit_address_port: Audit Process and Port
    ✔  Port 5432 should be listening
    ✔  Port 5432 addresses should include "127.0.0.1"
    ✔  Port 5432 protocols should cmp == "tcp"
    ✔  Processes postgres should exist
    ✔  Processes postgres users should include "postgres"
    ✔  User postgres should exist


Profile Summary: 2 successful controls, 0 control failures, 0 controls skipped
Test Summary: 11 successful, 0 failures, 0 skipped

出力は、コントロールとテストの両方が成功したことを示しています。

このセクションでは、最初のInSpecプロファイルとコントロールを作成し、それらを使用してテストを整理しました。 いくつかのInSpecリソースを使用して、正しいバージョンのPostgreSQLがインストールされていること、PostgreSQLサービスが有効で正しく実行されていること、PostgreSQLユーザーがシステムに存在することを確認しました。 これで、構成を監査する準備が整いました。

ステップ4-PostgreSQL構成の監査

この手順では、いくつかのPostgreSQL構成値を監査します。これにより、これらの構成ファイルを操作するための基盤が得られ、必要に応じてPostgreSQL構成パラメーターを監査できます。

PostgreSQLインストールを監査するテストができたので、PostgreSQL構成自体を監査します。 PostgreSQLには、必要に応じて調整するために使用できるいくつかの構成パラメーターがあり、これらはデフォルトで `+ / etc / postgresql / 10 / main / postgresql.conf +`にある構成ファイルに保存されます。 ロギング、パスワード暗号化、SSL、レプリケーション戦略など、さまざまなデプロイメントのPostgreSQL構成に関して異なる要件がある場合があります。これらの要件は構成ファイルで指定します。

https://www.inspec.io/docs/reference/resources/postgres_conf/ [+ postgres_conf +]リソースを使用して、PostgreSQL構成ファイルの内容の期待値に対して特定の名前付き構成オプションをテストします。

このテストでは、手動で設定するデフォルト以外のPostgreSQL設定値を想定しています。

好みのテキストエディターでPostgreSQL構成ファイルを開きます。

sudo nano /etc/postgresql/10/main/postgresql.conf

以下の構成値を設定します。 オプションが既にファイルに存在しているがコメントアウトされている場合は、 `#`を削除してコメントを外し、提供されている値を設定します。

/etc/postgresql/10/main/postgresql.conf

password_encryption = scram-sha-256
logging_collector = on
log_connections = on
log_disconnections = on
log_duration = on

設定した構成値:

  • 保存されたパスワードが常にscram-sha-256アルゴリズムで暗号化されていることを確認してください。

  • + logging collector +`を有効にします。これは、標準エラー( `+ stderr +)からログメッセージをキャプチャし、ログファイルにリダイレクトするバックグラウンドプロセスです。

  • PostgreSQLサーバーへの接続試行と成功した接続のロギングを有効にします。

  • セッション終了のロギングを有効にします。

  • 完了したすべてのステートメントの期間のロギングを有効にします。

構成ファイルを保存して終了します。 次に、PostgreSQLサービスを再起動します。

sudo service [email protected] restart

いくつかの設定オプションのみをテストしますが、 `+ postgres_conf +`リソースを使用して任意のPostgreSQL設定オプションをテストできます。

新しいプロファイル属性 + postgres conf dir`を使用して、 + / etc / postgresql / 10 / main`にあるPostgreSQL設定ディレクトリを渡します。 この設定ディレクトリは、すべてのオペレーティングシステムとプラットフォームで同じではないため、プロファイル属性として渡すことで、このプロファイルを異なる環境で再利用しやすくなります。

`+ inspec.yml +`ファイルを開きます:

nano inspec.yml

この新しい属性を `+ inspec.yml `の ` attributes +`セクションに追加します。

inspec.yml

...
 - name: postgres_conf_dir
   type: string
   default: '/etc/postgresql/10/main'

ファイルを保存して終了します。 次に、 `+ inspec.yml +`を編集したばかりであるため、次のコマンドを実行してInSpecプロファイルがまだ有効であることを確認します。

inspec check .

エラーがなければ、続行できます。 そうでない場合は、 `+ inspec.yml +`ファイルを開き、上記の行がファイルの最後にあることを確認します。

次に、施行する構成値を監査するコントロールを作成します。 次のコントロールをテストファイル `+ controls / postgresql.rb +`の最後に追加します。

controls / postgresql.rb

...
POSTGRES_CONF_DIR = attribute('postgres_conf_dir')
POSTGRES_CONF_PATH = File.join(POSTGRES_CONF_DIR, 'postgresql.conf')

control '3-postgresql' do
 impact 1.0
 title 'Audit PostgreSQL Configuration'
 desc 'Audits specific configuration options'

 describe postgres_conf(POSTGRES_CONF_PATH) do
   its('port') {should eq PORT}
   its('password_encryption') {should eq 'scram-sha-256'}
   its('ssl') {should eq 'on'}
   its('logging_collector') {should eq 'on'}
   its('log_connections') {should eq 'on'}
   its('log_disconnections') {should eq 'on'}
   its('log_duration') {should eq 'on'}
 end
end

ここで、2つの変数を定義します。

  • `+ POSTGRES_CONF_DIR `は、プロファイル設定で定義されている ` postgres_conf_dir +`属性を保持します。

  • `+ POSTGRES_CONF_PATH `はhttps://ruby-doc.org/core-2.6.2/File.html#method-c-join [`を使用して設定ファイル名と設定ディレクトリを連結することにより、設定ファイルの絶対パスを保持します File.join + `]。

次に、名前とメタデータを使用してコントロールを定義します。 次に、 `+ postgres_conf `リソースと ` eq `マッチャーを使用して、設定オプションに必要な値が正しいことを確認します。 保存して、 ` controls / postgresql.rb +`を終了します。

次に、次のコマンドでテストを実行します。

inspec exec .

テストに合格し、出力は次のようになります。

OutputProfile: InSpec Profile (PostgreSQL)
Version: 0.1.0
Target:  local://

 ✔  1-audit_installation: Audit PostgreSQL Installation
    ✔  System Package postgresql-10 should be installed
    ✔  System Package postgresql-10 version should cmp >= "10"
    ✔  Service [email protected] should be enabled
    ✔  Service [email protected] should be installed
    ✔  Service [email protected] should be running
 ✔  2-audit_address_port: Audit Process and Port
    ✔  Port 5432 should be listening
    ✔  Port 5432 addresses should include "127.0.0.1"
    ✔  Port 5432 protocols should cmp == "tcp"
    ✔  Processes postgres should exist
    ✔  Processes postgres users should include "postgres"
    ✔  User postgres should exist
 ✔  3-postgresql: Audit PostgreSQL Configuration
    ✔  PostgreSQL Configuration port should eq "5432"
    ✔  PostgreSQL Configuration password_encryption should eq "scram-sha-256"
    ✔  PostgreSQL Configuration ssl should eq "on"
    ✔  PostgreSQL Configuration logging_collector should eq "on"
    ✔  PostgreSQL Configuration log_connections should eq "on"
    ✔  PostgreSQL Configuration log_disconnections should eq "on"
    ✔  PostgreSQL Configuration log_duration should eq "on"


Profile Summary: 3 successful controls, 0 control failures, 0 controls skipped
Test Summary: 18 successful, 0 failures, 0 skipped

出力は、3つのコントロールとすべてのテストがスキップされたテストまたはコントロールなしで成功したことを示しています。

このステップでは、https://www.inspec.io/docs/reference/resources/postgres_conf/ [+ postgres_conf +]リソースを使用して、構成ファイルから特定のPostgreSQL構成値をテストする新しいInSpecコントロールを追加しました。 このセクションでいくつかの値を監査しましたが、これを使用して、構成ファイルの構成オプションをテストできます。

ステップ5-PostgreSQLクライアント認証の監査

PostgreSQL構成のテストをいくつか作成したので、クライアント認証のテストをいくつか作成します。 これは、さまざまな種類のユーザーに対して特定の認証方法を保証する必要があるインストールにとって重要です。たとえば、ローカルでPostgreSQLに接続するクライアントが常にパスワードで認証する必要があることを確認したり、特定のIPアドレスまたはIPアドレス範囲からの接続を拒否したりするなど。

セキュリティが懸念されるPostgreSQLインストールの重要な設定は、暗号化されたパスワード認証のみを許可することです。 PostgreSQL 10 2つのパスワード暗号化方法をサポートクライアント認証:https://en.wikipedia.org/wiki/MD5 [ + md5 +]およびhttps://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism [+ scram-sha-256 +]。 このテストでは、すべてのクライアントにパスワード暗号化が必要になるため、クライアント構成ファイルのすべてのクライアントの「+ METHOD」フィールドを「+ md5 」または「 scram-sha-256 」に設定する必要があります。 これらのテストでは、 ` md5 `よりも安全であるため、 ` scram-sha-256 +`を使用します。

デフォルトでは、 `+ local `クライアントは ` pg_hba.conf `ファイルに ` peer `認証方法を持っています。 テストのために、これらを ` scram-sha-256 `に変更する必要があります。 ` / etc / postgresql / 10 / main / pg_hba.conf`ファイルを開きます:

sudo nano /etc/postgresql/10/main/pg_hba.conf

ファイルの上部にはコメントが含まれています。 下にスクロールして、認証タイプが「+ local 」である非コメント行を探し、認証方法を「 peer 」から「 scram-sha-256 +」に変更します。 たとえば、次のように変更します。

/etc/postgresql/10/main/pg_hba.conf

...
local   all             postgres                                peer
...

to:

/etc/postgresql/10/main/pg_hba.conf

...
local   all             postgres                                scram-sha-256
...

最後に、 `+ pg_hba.conf +`設定は次のようになります。

/etc/postgresql/10/main/pg_hba.conf

...
local   all             postgres                                scram-sha-256

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     scram-sha-256
# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     scram-sha-256
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256
...

構成ファイルを保存して終了します。 次に、PostgreSQLサービスを再起動します。

sudo service [email protected] restart

このテストでは、https://www.inspec.io/docs/reference/resources/postgres_hba_conf/ [+ postgres_hba_conf +]リソースを使用します。 このリソースは、 `+ pg_hba.conf `ファイルで定義されたクライアント認証データをテストするために使用されます。 このリソースへのパラメーターとして、 ` pg_hba.conf +`ファイルのパスを渡します。

コントロールは、2つの「+ describe 」ブロックで構成され、それぞれ「 local 」と「 host 」クライアントの両方の「 auth_method 」フィールドをチェックして、両方が「 scram-sha-256 」に等しいことを確認します。 テキストエディタで ` controls / postgresql.rb +`を開きます。

nano controls/postgresql.rb

次のコントロールをテストファイル `+ controls / postgresql.rb +`の最後に追加します。

controls / postgresql.rb

POSTGRES_HBA_CONF_FILE = File.join(POSTGRES_CONF_DIR, 'pg_hba.conf')

control '4-postgres_hba' do
 impact 1.0
 title 'Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf'
 desc 'Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf. Do not allow untrusted authentication methods.'

 describe postgres_hba_conf(POSTGRES_HBA_CONF_FILE).where { type == 'local' } do
   its('auth_method') { should all eq 'scram-sha-256' }
 end

 describe postgres_hba_conf(POSTGRES_HBA_CONF_FILE).where { type == 'host' } do
   its('auth_method') { should all eq 'scram-sha-256' }
 end
end

このコードブロックでは、新しい変数 + POSTGRES_HBA_CONF_FILE +`を定義して、 `+ pg_hba.conf +`ファイルの絶対位置を保存します。 https://ruby-doc.org/core-2.6.2/File.html#method-c-join [+ File.join `]は、2つのファイルパスセグメントを ` / `で連結するRubyメソッドです。 ここで使用して、前のセクションで宣言した ` POSTGRES_CONF_DIR `変数をPostgreSQL設定ファイル ` pg_hba.conf `と結合します。 これにより、 ` pg_hba.conf `ファイルの絶対ファイルパスが生成され、 ` POSTGRES_HBA_CONF_FILE +`変数に保存されます。

その後、コントロールとそのメタデータを宣言して構成します。 最初の「+ describe 」ブロックは、クライアントタイプが「 local 」であるすべての設定エントリが、認証方法として「 scram-sha-256 」も持っていることをチェックします。 2番目の ` describe `ブロックは、クライアントタイプが ` host `の場合に同じことを行います。 保存して、 ` controls / postgresql.rb +`を終了します。

PostgreSQL HBA設定への「+ Read 」アクセスは所有者とグループ(「 postgres 」ユーザー)にのみ許可されるため、このコントロールを「 postgres +」ユーザーとして実行します。 次を実行してプロファイルを実行します。

sudo -u postgres inspec exec .

出力は次のようになります。

OutputProfile: InSpec Profile (PostgreSQL)
Version: 0.1.0
Target:  local://

 ✔  1-audit_installation: Audit PostgreSQL Installation
    ✔  System Package postgresql-10 should be installed
    ✔  System Package postgresql-10 version should cmp >= "10"
    ✔  Service [email protected] should be enabled
    ✔  Service [email protected] should be installed
    ✔  Service [email protected] should be running
 ✔  2-audit_address_port: Audit Process and Port
    ✔  Port 5432 should be listening
    ✔  Port 5432 addresses should include "127.0.0.1"
    ✔  Port 5432 protocols should cmp == "tcp"
    ✔  Processes postgres should exist
    ✔  Processes postgres users should include "postgres"
    ✔  User postgres should exist
 ✔  3-postgresql: Audit PostgreSQL Configuration
    ✔  PostgreSQL Configuration port should eq "5432"
    ✔  PostgreSQL Configuration password_encryption should eq "scram-sha-256"
    ✔  PostgreSQL Configuration ssl should eq "on"
    ✔  PostgreSQL Configuration logging_collector should eq "on"
    ✔  PostgreSQL Configuration log_connections should eq "on"
    ✔  PostgreSQL Configuration log_disconnections should eq "on"
    ✔  PostgreSQL Configuration log_duration should eq "on"
 ✔  4-postgres_hba: Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf
    ✔  Postgres Hba Config /etc/postgresql/10/main/pg_hba.conf with type == "local" auth_method should all eq "scram-sha-256"
    ✔  Postgres Hba Config /etc/postgresql/10/main/pg_hba.conf with type == "host" auth_method should all eq "scram-sha-256"


Profile Summary: 4 successful controls, 0 control failures, 0 controls skipped
Test Summary: 20 successful, 0 failures, 0 skipped

この出力は、追加した新しいコントロールと以前のすべてのコントロールが成功したことを示しています。 また、プロファイル内のすべてのテストが成功したことも示します。

このステップでは、PostgreSQLクライアント認証設定を正常に監査するコントロールをプロファイルに追加し、https://www.inspec.io/docsを使用してすべてのクライアントが + scram-sha-256 +`を介して認証されるようにします/ reference / resources / postgres_hba_conf / [+ postgres_hba_conf +`]リソース。

結論

InSpecをセットアップし、PostgreSQL 10インストールを正常に監査しました。 このプロセスでは、InSpec DSL、マッチャー、リソース、プロファイル、属性、CLIなどのInSpecツールの選択を使用しました。 ここから、InSpecが提供する他のリソースをドキュメントのhttps://www.inspec.io/docs/reference/resources [リソースセクション]に組み込むことができます。 InSpecは、特定のニーズに合わせてhttps://www.inspec.io/docs/reference/dsl_resource[custom resources]を定義するメカニズムも提供します。 これらのカスタムリソースは、通常のRubyクラスとして記述されています。

また、パブリックに共有されたInSpecプロファイルを含むhttps://supermarket.chef.io/[Chef supermarket]のhttps://supermarket.chef.io/tools?type=compliance_profile[`+Compliance Profiles + `]セクションを調べることもできます。直接実行することも、独自のプロファイルで拡張することもできます。 また、シェフスーパーマーケットで自分のプロフィールを一般の人と共有することもできます。

https://www.chef.io/ [+ Chef +]やhttps://www.habitat.sh/ [+ Habitat +]など、Chefユニバースの他のツールを調べることで、さらに先へ進むことができます。 InSpecはHabitatと統合されていますこれにより、Habitatにパッケージ化されたアプリケーションとともにコンプライアンスコントロールを出荷し、継続的に実行することができます。 tutorialsページで公式およびコミュニティのInSpecチュートリアルを探索できます。 より高度なInSpecリファレンスについては、公式のhttps://www.inspec.io/docs[InSpecドキュメント]を確認してください。