Ubuntu18.04でInSpecを使用してPostgreSQLデータベースを監査する方法

投稿日: 2019-11-08 2022-04-20
タグ: postgresql, Ubuntu 18.04

著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。

序章

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

テストするポリシー要件を指定するために、InSpecには監査コントロールが含まれています。従来、開発者は手動でポリシー要件を適用し、多くの場合、変更を本番環境にデプロイする直前にこれを実行します。ただし、InSpecを使用すると、開発者は製品開発のすべての段階でコンプライアンスを継続的に評価でき、開発プロセスの早い段階で問題を解決するのに役立ちます。 Rubyで記述されたDSLテストツールであるRSpec上に構築されたInSpecDSL（ドメイン固有言語）は、監査コントロールの記述に使用される構文を指定します。

InSpecには、システムの特定の部分の構成を支援し、監査制御の作成を簡素化するためのリソースのコレクションも含まれています。利用できない特定のソリューションを定義する必要がある場合は、独自のカスタムリソースを作成する機能があります。ユニバーサルマッチャーを使用すると、すべてのInSpecテストでリソース値を期待値と比較できます。

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

前提条件

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

Ubuntu 18.04での初期サーバーセットアップを使用してセットアップされた1つのUbuntu18.04サーバー。これには、sudo非rootユーザーとファイアウォールが含まれます。
このインストールガイドに従って動作するPostgreSQL10のインストール。

ステップ1—環境の準備

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

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

cd ~

次に、curlを使用してバイナリをダウンロードします。

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

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

sha256sum inspec_3.7.11-1_amd64.deb

各バイナリのチェックサムはInSpecダウンロードページにリストされているため、ダウンロードページにアクセスして、このコマンドからの出力と比較してください。

Output
e665948f9c0441e8648b08f8d3c8d34a86f9e994609877a7e4853c012dbc7523 inspec_3.7.11-1_amd64.deb

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

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

sudo dpkg -i inspec_3.7.11-1_amd64.deb

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

inspec version

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

Output
3.7.11

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

この後、パッケージをインストールしたのでinspec_3.7.11-1_amd64.debは不要になったため、削除できます。

rm inspec_3.7.11-1_amd64.deb

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

ステップ2—最初のInSpecテストを完了する

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

組み込みのInSpec監査リソースであるosリソースを使用して、システムが実行されているプラットフォームをテストします。 eqマッチャーも使用します。 eqマッチャーは、2つの値が正確に等しいかどうかをテストするユニバーサルマッチャーです。

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

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

nano os_family.rb

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

os_family.rb

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

このテストでは、ターゲットシステムのオペレーティングシステムファミリがdebianであることを確認します。その他の可能な値は、windows、unix、bsdなどです。完全なリストは、osリソースドキュメントにあります。ファイルを保存して終了します。

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

inspec exec os_family.rb

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

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からデフォルトのプロファイル名を生成します。（次のセクションでは、PostgreSQL InSpecプロファイルの作成を開始するInSpecプロファイルを使用します。）ここで、InSpecはVersionをnot specifiedとして表示します。プロファイルでバージョンのみを指定します。

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

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

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

これで、失敗したテストの出力がどのようになるかがわかります。 os_family.rbを開きます：

nano os_family.rb

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

os_family.rb

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

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

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

inspec exec os_family.rb

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

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監査では、PostgreSQLという名前のInSpecprofile内にさまざまなInSpecコントロールを作成します。

InSpec control は、関連するテストの高レベルのグループです。コントロール内には、複数のdescribeブロックと、影響レベル、タイトル、説明、タグなどのテストを説明するメタデータを含めることができます。 InSpecプロファイルは、依存関係の管理とコードの再利用をサポートするコントロールを編成します。これらは両方とも、テストの複雑さの管理に役立ちます。また、 ChefSupermarketを介してテストをパッケージ化して一般に共有する場合にも役立ちます。プロファイルを使用して、通常のRubyクラスとして実装するカスタムリソースを定義できます。

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

inspec init profile PostgreSQL

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

cd PostgreSQL/

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

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

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

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

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

mv controls/example.rb controls/postgresql.rb

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

nano controls/postgresql.rb

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

コントロール/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('postgresql@10-main') do
    it {should be_enabled}
    it {should be_installed}
    it {should be_running}
  end
end

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

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

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

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

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

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 postgresql@10-main should be enabled
     ✔  Service postgresql@10-main should be installed
     ✔  Service postgresql@10-main should be running


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

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

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

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

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

nano inspec.yml

port属性をファイルの最後に追加します。ファイルの最後に以下を追加します。

inspec.yml

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

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

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

inspec check .

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

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

nano controls/postgresql.rb

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

コントロール/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ブロックには、 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ブロックには、processesリソースを含めます。 processesリソースを使用して、システムで実行されているプログラムのプロパティをテストします。まず、postgresプロセスがシステムに存在することを確認してから、usersマッチャーを使用して、postgresユーザーがpostgresプロセスを所有していることをテストします。

3番目のdescribeブロックには、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 postgresql@10-main should be enabled
     ✔  Service postgresql@10-main should be installed
     ✔  Service postgresql@10-main 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構成に関して、さまざまな要件があります。これらの要件は、構成ファイルで指定します。

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 postgresql@10-main 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の最後に次のコントロールを追加します。

コントロール/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は、 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 postgresql@10-main should be enabled
     ✔  Service postgresql@10-main should be installed
     ✔  Service postgresql@10-main 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つのコントロールとすべてのテストが、スキップされたテストまたはコントロールなしで成功したことを示しています。

このステップでは、postgres_confリソースを使用して構成ファイルから特定のPostgreSQL構成値をテストする新しいInSpecコントロールを追加しました。このセクションではいくつかの値を監査しましたが、これを使用して、構成ファイルから任意の構成オプションをテストできます。

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

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

セキュリティが懸念されるPostgreSQLインストールの重要な構成は、暗号化されたパスワード認証のみを許可することです。 PostgreSQL 10 は、クライアント認証用に md5とscram-sha-256の2つのパスワード暗号化方式をサポートしています。このテストでは、すべてのクライアントのパスワード暗号化が必要になるため、クライアント構成ファイルのすべてのクライアントの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
...

に：

/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 postgresql@10-main restart

このテストでは、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の最後に次のコントロールを追加します。

コントロール/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

このコードブロックでは、pg_hba.confファイルの絶対位置を格納するために、新しい変数POSTGRES_HBA_CONF_FILEを定義します。 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を保存して終了します。

PostgreSQLHBA構成への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 postgresql@10-main should be enabled
     ✔  Service postgresql@10-main should be installed
     ✔  Service postgresql@10-main 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クライアント認証構成を正常に監査するコントロールをプロファイルに追加し、postgres_hba_confリソースを使用してscram-sha-256を介してすべてのクライアントが認証されるようにしました。

結論

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

ChefスーパーマーケットのComplianceProfiles セクションを探索することもできます。このセクションには、直接実行したり、独自のプロファイルで拡張したりできる、公に共有されたInSpecプロファイルが含まれています。シェフのスーパーマーケットで一般の人と自分のプロフィールを共有することもできます。

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

getdocs

13036