セキュリティは、すべてのシステムがデータを可能な限り保護するために必須です。ハッキングされるリスクが常にある場合でも、セキュリティチェックリストに従うことで、このリスクを大幅に減らすことができます。基本的なセキュリティチェックリストには、ファイアウォール構成、データ暗号化、認証ポリシーなどが含まれます。Debianベースのオペレーティングシステムでデータを保護するためのもう1つの重要なツールは、AppArmorです。このブログでは、PostgreSQLおよびTimescaleDBデータベース用にそれを構成する方法とその内容を説明します。
AppArmorとは何ですか？
AppArmorは、UbuntuおよびDebian（とりわけ）オペレーティングシステムにデフォルトで含まれており、プログラムを限られたリソースセットに制限するための強制アクセス制御（MAC）システムです。カーネルにロードされたプロファイルを使用して機能します。これらのプロファイルは、次の2つのモードで構成できます。
-
適用：このモードでロードされたプロファイルは、プロファイルで定義されたポリシーを適用し、ポリシー違反を報告します試みます。
-
不満：このモードのプロファイルはポリシーを適用せず、代わりにポリシー違反の試みを報告します。
また、AppArmorでは、執行モードと苦情モードのプロファイルを混在させることができます。
AppArmorプロファイルは/etc/apparmor.d/にあります。独自のプロファイルを作成してそこに移動するか、AppArmorリポジトリを確認することができます。新しいAppArmorプロファイルを作成する方法を見てみましょう。
まず、これを処理するために必要なパッケージをインストールしましょう：
$ apt install apparmor-profiles apparmor-utilsAppArmorが有効になっているかどうかを確認します：
$ systemctl status apparmor.service$ aa-status
apparmor module is loaded.
31 profiles are loaded.
29 profiles are in enforce mode.
/snap/snapd/11588/usr/lib/snapd/snap-confine
/snap/snapd/11588/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
...上記のパス/etc/apparmor.d/を確認すると、usr.sbin.tcpdumpやusr.sbin.tracerouteなどの基本的なプロファイルが表示されます。それでは、PostgreSQLまたはTimescaleDBの新しいプロファイルを作成しましょう。このために、このプロファイルを例として使用できます。そのプロファイルに基づいて、PostgreSQLのバージョンをより具体的に置き換えます。この場合、PostgreSQL13を使用します。
# Author: Felix Geyer <[email protected]>
#include <tunables/global>
/usr/lib/postgresql/13/bin/postgres {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/ssl_keys>
/etc/postgresql/** r,
/usr/share/postgresql/** r,
/var/lib/postgresql/** rwl,
/{,var/}run/postgresql/** rw,
owner @{PROC}/13/oom_adj rw,
}$ cat /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres | sudo apparmor_parser -aこのプロファイルの何かを変更したい場合は、それをリロードする必要があります：
$ apparmor_parser -r /etc/apparmor.d/usr.lib.postgresql.13.bin.postgres次のコマンドを使用して、プロファイルに不平モードを割り当てることができます。
$ aa-complain /usr/lib/postgresql/13/bin/postgres次に、/ var / log内のsyslogファイルをチェックして、AppArmorの構成が正しいかどうか、または何かを変更する必要があるかどうかを確認できます。安全になったら、次のコマンドを実行してモードを強制に変更できます。
$ aa-enforce /usr/lib/postgresql/13/bin/postgresログをフィルタリングして、許可または拒否されたアクションを探すことができます：
Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.111028] audit: type=1400 audit(1624650482.537:103): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17405/oom_score_adj" pid=17405 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113
Jun 25 19:48:02 ip-172-31-18-94 kernel: [ 5160.112524] audit: type=1400 audit(1624650482.541:104): apparmor="ALLOWED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17404/oom_score_adj" pid=17404 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113
Jun 25 19:50:02 ip-172-31-18-94 kernel: [ 5280.141262] audit: type=1400 audit(1624650602.569:112): apparmor="DENIED" operation="open" profile="/usr/lib/postgresql/13/bin/postgres" name="/proc/17518/oom_score_adj" pid=17518 comm="postgres" requested_mask="w" denied_mask="w" fsuid=113 ouid=113$ aa-disable /etc/apparmor.d/usr.lib.postgresql.13.bin.postgresそして、サービスをリロードする必要があります：
$ systemctl reload apparmor.serviceAppArmorを無効にする場合は、次のコマンドを実行できます：
$ systemctl stop apparmor
$ systemctl disable apparmor
もちろん、これは実稼働環境では推奨されません。少なくとも、すべてのプロファイルでComplainモードを使用して実行し続ける必要があります。そうすれば、ログをチェックして予期しない動作を探すことができます。
ClusterControlとAppArmorでPostgreSQLとTimescaleDBを使用する方法
ClusterControlは、AppArmorのようなLinuxカーネルセキュリティモジュールを管理しません。 ClusterControlを使用してPostgreSQLまたはTimescaleDBクラスターをデプロイする場合、デプロイプロセス中にClusterControlでAppArmorを無効にして、エラーのリスクを軽減するかどうかを指定できます。
無効にしたくない場合は、本番環境に推奨されます環境では、Complainモードを使用し、サーバーのログを監視して、AppArmorが正しく構成されていることを確認できます。その後、上記の手順に従って強制に変更できます。
AppArmorの構成の詳細については、Ubuntuの公式サイトをご覧ください。