Ubuntu 18.04でInSpecを使用してPostgreSQLデータベースを監査する方法

著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにFree and Open Source Fundを選択しました。

前書き

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

テストするポリシー要件を指定するために、InSpecにはaudit controlsが含まれています。従来、開発者はポリシー要件を手動で適用し、多くの場合、実稼働環境に変更を展開する直前にこれを行います。ただし、InSpecを使用すると、開発者は製品開発のあらゆる段階でコンプライアンスを継続的に評価できるため、開発プロセスの初期段階で問題を解決できます。 Rubyで記述されたDSLテストツールであるRSpec上に構築されたInSpec DSL (Domain Specific Language)は、監査コントロールの記述に使用される構文を指定します。

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

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

前提条件

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

sudo非rootユーザーとファイアウォールを含むInitial Server Setup with Ubuntu 18.04を使用してセットアップされた1つのUbuntu18.04サーバー。
このinstallation guideに続く、動作中のPostgreSQL10インストール。

[[step-1 -—- preparing-the-environment]] ==ステップ1-環境の準備

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

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

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 downloads pageにリストされているため、ダウンロードページにアクセスして、このコマンドからの出力と比較してください。

Outpute665948f9c0441e8648b08f8d3c8d34a86f9e994609877a7e4853c012dbc7523 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のバージョンを示す出力が表示されます。

Output3.7.11

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

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

rm inspec_3.7.11-1_amd64.deb

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

[[step-2 -—- completing-your-first-inspec-test]] ==ステップ2—最初のInSpecテストを完了する

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

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

InSpecテストは、describeブロックで構成されます。このブロックには、1つ以上のitステートメントとitsステートメントが含まれ、それぞれがリソースの機能の1つを検証します。各ステートメントは、システムの特定の状態の期待値をassertionsとして記述します。アサーションを作成するために含めることができる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 resource documentationにあります。ファイルを保存して終了します。

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

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プロファイルの作成を開始するInSpecprofilesを使用します。）ここでは、バージョンを指定できるのはでのみバージョンを指定できるため、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インストールをテストするための監査プロファイルの構築を開始します。

[[step-3 -—- auditing-your-postgresql-installation]] ==ステップ3—PostgreSQLインストールの監査

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

InSpeccontrolは、関連するテストの高レベルのグループです。コントロール内には、複数のdescribeブロックと、影響レベル、タイトル、説明、タグなどのテストを説明するメタデータを含めることができます。 InSpecプロファイルは、依存関係の管理とコードの再利用をサポートするためにコントロールを編成し、どちらもテストの複雑さの管理に役立ちます。また、Chef Supermarketを介してテストをパッケージ化し、一般の人々と共有する場合にも役立ちます。プロファイルを使用して、通常の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

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

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('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リソースを使用し、PostgreSQL 10サービス名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が正しいポート、アドレス、およびプロトコルでリッスンすることを保証する新しいコントロールを作成します。

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

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ブロックには、基本的なポートプロパティをテストするための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ユーザーがシステムに存在することを確認しました。これで、構成を監査する準備が整いました。

[[step-4 -—- auditing-your-postgresql-configuration]] ==ステップ4—PostgreSQL構成の監査

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

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

PostgreSQL構成ファイルの内容の期待値に対して特定の名前付き構成オプションをテストするpostgres_confリソースを使用します。

このテストでは、手動で設定するデフォルト以外の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の最後に次のコントロールを追加します。

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は、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コントロールを追加しました。このセクションでいくつかの値を監査しましたが、これを使用して、構成ファイルの構成オプションをテストできます。

[[step-5 -—- auditing-postgresql-client-authentication]] ==ステップ5—PostgreSQLクライアント認証の監査

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

セキュリティが懸念されるPostgreSQLインストールの重要な設定は、暗号化されたパスワード認証のみを許可することです。クライアント認証用のPostgreSQL10supports two password encryption methods：md5および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 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の最後に次のコントロールを追加します。

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ファイルの絶対位置を格納します。 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 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をセットアップし、PostgreSQL 10インストールを正常に監査しました。このプロセスでは、InSpec DSL、マッチャー、リソース、プロファイル、属性、CLIなどのInSpecツールの選択を使用しました。ここから、InSpecが提供する他のリソースをドキュメントのResources sectionに組み込むことができます。 InSpecは、特定のニーズに合わせてcustom resourcesを定義するためのメカニズムも提供します。これらのカスタムリソースは、通常のRubyクラスとして記述されています。

直接実行したり、独自のプロファイルで拡張したりできる、パブリックに共有されたInSpecプロファイルを含むChef supermarketのCompliance Profilesセクションを調べることもできます。 Chef Supermarketで自分のプロフィールを一般大衆と共有することもできます。

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

TOC

Ubuntu 18.04でInSpecを使用してPostgreSQLデータベースを監査する方法

前書き

前提条件

結論

Related