sql >> データベース >  >> RDS >> PostgreSQL

SQLファイアウォールを使用してPostgreSQLデータベースをサイバー攻撃から保護する方法

    今日の世界では、組織は情報資産に対するサイバー攻撃の前例のないレベルの脅威にますます直面しています。

    サイバー攻撃にはさまざまな形態があります。そのような攻撃の1つは、SQLインジェクションと呼ばれます。 。 SQLインジェクションでは、不正なプレーヤーがあらゆるシステムのバックエンドデータベースを標的にします。通常、これらのシステムは公開されています。ハッカーは、一見無害で定期的なクエリをデータベースに送信しようとします。ただし、表示されないはずの情報を公開したり、間違った情報でデータベースを破壊したり、システムをクラッシュさせたりする可能性のあるパラメータを除きます。

    サイバーセキュリティのスペシャリストは、これらの攻撃の高度化に先んじるために常に時間と競争しており、ほとんどの大規模な戦争と同様に、今ではあらゆる面で戦っています。つまり、セキュリティは、データベース層を含む、アプリケーションのスタックのすべての層に実装する必要があります。

    経験豊富なDBAは通常、役割ベースのアクセス制御（RBAC）、フェデレーション認証、監査、SSLなどの手段でデータベースを保護しようとします。ただし、データベースを保護するための追加の対策も検討する必要があります。

    そのような保護手段の1つは、データベースファイアウォールです。通常のファイアウォールと同様に、データベースファイアウォールは、ホワイトリストまたはブラックリストに基づいてトラフィックを除外します。また、システムアクセスパターンから「学習」して、信頼できるステートメントと信頼できないステートメントを理解することもできます。このようなツールを使用すると、SQLインジェクションに対する強力な保護レイヤーが追加されます。

    この記事では、SQLファイアウォールについて説明します。 、PostgreSQLデータベースを保護するためのデータベースファイアウォール。 SQLファイアウォールは、PostgreSQLテクノロジーのリーダーである2ndQuadrantによって構築およびサポートされています。

    SQLファイアウォールの仕組み

    SQLファイアウォールは、PostgreSQL9.4以降の拡張機能として提供されます。現在、PostgreSQLバージョン10までサポートされていますが、それ以降のバージョンをサポートするためのさらなる作業が進行中です。

    これは拡張機能であるため、SQLファイアウォールのインストールと構成は非常に簡単です。構成が完了すると、個々のユーザーのデータベースに対してSQLステートメントをホワイトリストに登録するために使用できます。ホワイトリストは、アプリケーションの一般的なワークロードで拡張機能を「トレーニング」することで得られます。通常は、考えられるすべてのシナリオをカバーする一連のテストを繰り返し実行することで得られます。ホワイトリストが微調整されて完成したら、エクスポートして、同様のワークロードを提供する他のPostgreSQLインスタンスにインポートできます。

    たとえば、アプリケーションを起動する前に、構成された各ユーザーは、制御された環境でデータベースに対して本番品質のサンプルワークロードを実行できます。人間のユーザーアカウントは読み取り専用クエリの実行のみを許可され、アプリケーションのユーザーアカウントは読み取りと書き込みの両方の実行を許可される場合があります。次に、SQLファイアウォールは、人間とアプリケーションの両方のユーザーアカウントの読み取りクエリと、アプリケーションユーザーアカウントのみの書き込みクエリをホワイトリストに登録します。その後、人間のユーザーがINSERT、DELETE、またはUPDATEを実行しようとすると、SQLファイアウォールはその操作を拒否します。アプリケーションが進化するにつれて、ホワイトリストは変化するワークロードに合わせて再トレーニングすることもできます。

    ブロックされたすべてのステートメントはSQLファイアウォールによってログに記録されます。つまり、運用チームはこれらのログをログ管理ソリューションに送信し、例外が発生するたびにアラートを受け取ることができます。

    環境の設定

    この記事では、Red Hat Enterprise Linux7で実行されているシングルノードPostgreSQL10インスタンスにSQLファイアウォールをインストールします。執筆時点では、RHEL /CentOS7とPostgreSQL10がサポートされている最高のバージョンです。ただし、前述のように、さらなるサポートが行われています。

    注

    [SQLファイアウォールは、24時間年中無休のサポートのお客様が利用できる商用ライセンス製品であることに注意してください。 2ndQuadrantの公開Webサイトからダウンロードすることはできません。]

    ステップ1：PostgreSQL10をインストールする

    テストシステムは、Red Hat EnterpriseLinux7.2を実行しているAmazonEC2インスタンスです。

    # cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

    次のコマンドを実行して、PostgreSQL 10（x86-64）のRPMリポジトリをダウンロードします。

    # yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm -y

    次に、サーバーとクライアントパッケージをインストールします。

    # yum install postgresql10-server postgresql10 -y

    パッケージが正常にインストールされたら、initdbコマンドを実行してデータベースを初期化します。

    # /usr/pgsql-10/bin/postgresql-10-setup initdb

Initializing database ... OK

    次に、postgresql.confファイルに次の変更を加えます。デフォルトでは、/ var / lib / pgsql / 10 /data/ディレクトリの下にあります。

    listen_addresses = '*'

    次に、次の行をpg_hba.confファイルに追加します（これもデフォルトでは、/ var / lib / pgsql / 10 / data /ディレクトリの下にあります）。

    host    all all    <our IP address range>    md5

    次に、PostgreSQLサービスを開始し、自動的に開始できるようにします。

    # systemctl start postgresql-10.service
# systemctl enable postgresql-10.service

    最後に、postgresユーザーとしてpsqlからデータベースインスタンスにログインし、パスワードを変更します。

    # su - postgres
-bash-4.2$ psql
psql (10.12)
Type "help" for help.

postgres=# \password
Enter new password:
Enter it again:
postgres=#

    ステップ2：サンプルデータベースを復元する

    本番システムをエミュレートするために、PostgreSQLサーバーに2つのサンプルデータベースを復元しました。これらのデータベースは公開されています：

    • パギラ ：人気のあるMySQLSakilaデータベースのPostgreSQLバージョン
    • チヌーク ：デジタルメディアストアに関するデータベース

    ステップ3：ロールとユーザーを作成する

    データベースを作成したら、2つのユーザーロールを作成します。 1つは「human_user」と呼ばれ、もう1つは「app_user」と呼ばれます。

    human_userロールは、バックエンドから、またはクライアントツールを使用してデータベースにアクセスするすべてのユーザーを表します。 app_userロールは、アプリケーションがデータベースへの接続に使用するアカウントを表します。 

    psql -d postgres -c "CREATE ROLE human_user WITH  NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';"
psql -d postgres -c "CREATE ROLE app_user WITH  NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';"

    次に、postgresユーザーとして次のコマンドを実行することにより、ユーザーロールにchinookおよびpagilaデータベースにアクセスするためのアクセス許可が付与されます。

    $ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO app_user;"

$ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;"

$ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;"

$ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO human_user;"

$ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;"

$ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;"

    ステップ4：SQLファイアウォールのインストール

    SQLファイアウォールのインストールは簡単なプロセスです。まず、パッケージをインストールします。

    # rpm -ivh postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm

warning: postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID ******: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...

1:postgresql10-sqlfirewall-3.0-1.el################################# [100%]

    次に、shared_preload_librariesパラメーターを変更してpostgresql.confファイルを更新します。

    shared_preload_libraries = 'sqlfirewall'

    完了したら、PostgreSQLサービスを再起動します。

    # systemctl restart postgresql-10.service

    サービスが再起動したら、postgresユーザーとしてインスタンスにログインし、両方のサンプルデータベースに拡張機能を追加します。

    $ psql -U postgres -d chinook -c "CREATE EXTENSION sqlfirewall;"
Password for user postgres:
CREATE EXTENSION
-bash-4.2$ psql -U postgres -d pagila -c "CREATE EXTENSION sqlfirewall;"
Password for user postgres:
CREATE EXTENSION

    次の画像は、両方のデータベースにインストールされている拡張機能を示しています。両方のデータベースにも「sqlfirewall」と呼ばれる特別なスキーマが作成されていることに注意してください。このスキーマには、SQLファイアウォールの操作に関連するすべてのデータベースオブジェクトが含まれています。

    また、「sqlfirewall_manager」という名前の新しいロールが自動的に作成されていることもわかります。この役割に追加されたユーザーは、sqlfirewallスキーマの関数とビューにアクセスできます。

    ステップ5：SQLファイアウォールの構成

    次に、いくつかのパラメータが postgresql.confに追加されます。 ファイル。 Red Hat Enterprise Linuxおよびその派生ディストリビューションの場合、このファイルのデフォルトのディレクトリの場所は/ var / lib / pgsql / 10 /data/です。

    次のコードスニペットでは、ファイルを編集し、いくつかのパラメーターを追加しています。

    # vim /var/lib/pgsql/10/data/postgresql.conf

sqlfirewall.whitelist = 'verbose'
sqlfirewall.track = 'all'
sqlfirewall.track_utility = 'true'
sqlfirewall.save = 'true'

    次に、すべての構成をリロードします。

    $ psql -U postgres -d postgres
Password for user postgres:
psql (10.12)
Type "help" for help.

postgres=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

    次に、プロセスを1秒間スリープさせます。

    postgres=# SELECT pg_sleep(1);
 pg_sleep
----------
(1 row)

    次に、両方のデータベースのホワイトリストのステータスを確認します。手順に従った場合は、両方のデータベースでホワイトリストを有効にする必要があります。

    postgres=# \connect pagila
You are now connected to database "pagila" as user "postgres".
pagila=# show sqlfirewall.whitelist;
 sqlfirewall.whitelist
-----------------------
 verbose
(1 row)

pagila=# \connect chinook;
You are now connected to database "chinook" as user "postgres".
chinook=# show sqlfirewall.whitelist;
 sqlfirewall.whitelist
-----------------------
 verbose
(1 row)

    追加したパラメータを見てみましょう。

    sqlfirewall.whitelist パラメータは、ファイアウォールのホワイトリスト機能を有効にするために使用されます。このパラメーターには、「verbose」または「protect」の2つの値のいずれかを指定できます。

    詳細オプションを使用すると、SQLファイアウォールは、ホワイトリストに登録されていないクエリを実行しようとすると、ユーザーに警告メッセージを表示します。値がprotectedに設定されている場合、SQLファイアウォールは一般的な「permissiondenied」メッセージを表示します。ベストプラクティスとして、値を「保護」に設定することをお勧めします。これにより、ハッカーはコマンドが拒否された理由を知ることができなくなります。このパラメータは、デモンストレーションのみを目的として「verbose」に設定しています。

    sqlfirewall.trackに割り当てられた値 およびsqlfirewall.track_utility パラメータは、SQLファイアウォールがホワイトリストの目的ですべてのステートメントを追跡していることを確認します。

    最後に、 sqlfirewall.saveを設定します パラメータを「true」に設定すると、サーバーが再起動された場合でも、ホワイトリストに記載されたステートメントが保持されます。

    SQLファイアウォールの実行

    SQLファイアウォールを実行するには、拡張機能に付属するいくつかの関数を呼び出す必要があります。

    ステップ1：SQLファイアウォール機能を理解する

    SQLファイアウォール拡張機能は、インストールされているデータベースのsqlfirewallスキーマにいくつかの関数を作成します。これらの関数のほとんどは、スーパーユーザーまたはsqlfirewall_managerロールのメンバーのみが実行できます。

    これらの機能のいくつかを簡単に見ていきましょう。

    sqlfirewall_whitelist_mode 使用する主な機能です。この関数は、特定のPostgreSQLユーザーのステートメントホワイトリストを有効にします。 2つのパラメータを取ります。1つはユーザー名、もう1つはホワイトリストモードです。

    ホワイトリストモード パラメータには次の3つの値を指定できます。

    • 「 RECORD」に設定されている場合 」、SQLファイアウォールは、ユーザーが実行したすべてのステートメントをユーザーのホワイトリストに記録します
    • 「 ENFORCE」に設定した場合 」、SQLファイアウォールはホワイトリストを適用します。ホワイトリストに含まれていないステートメントはエラーの原因になります
    • 「 OFF」の値 」はユーザーのホワイトリスト機能をオフにし、ユーザーはクエリをまったく実行できなくなります

    ユーザーのホワイトリストに登録されたクエリを削除する場合は、 sqlfirewall_whitelist_deleteを実行します 代わりに機能します。この関数は、ユーザー名という1つのパラメーターを取ります。実行すると、sqlfirewall_whitelist_delete関数は、ユーザーのホワイトリストに登録されたすべてのステートメントを削除します。

    sqlfirewall_whitelist_delete_entry 関数は、ユーザーのホワイトリストから個々のクエリIDを削除するために使用されます。これは、ユーザーに許可されているクエリが多すぎて微調整したい場合に便利です。この関数は、ユーザー名とクエリIDの2つのパラメーターを取ります。 sqlfirewallビューを確認すると、ホワイトリストから除外するクエリのIDを見つけることができます。

    sqlfirewall_whitelist_users 関数はパラメータを取りません。アカウントでホワイトリストを有効にしているユーザーのリストを返します。

    sqlfirewall_whitelist_export を使用して、ユーザーのホワイトリストをエクスポートできます。 働き。この関数は、ユーザー名と、ユーザーのホワイトリストに登録されたステートメントをエクスポートするファイル名の2つのパラメーターを取ります。ファイルは、PostgreSQLサーバープロセスが書き込みアクセスできる場所にある必要があります。

    sqlfirewall_whitelist_export関数と同様に、sqlfirewall_whitelist_import関数 ユーザーのエクスポートされたホワイトリストファイルを、そのユーザーの別のPostgreSQLインスタンスにインポートするために使用されます。この関数は、ユーザー名とインポートするファイルの2つのパラメーターも受け取ります。ファイルは、PostgreSQLサーバープロセスが読み取ることができる場所にある必要があります。

    また、ターゲットデータベースはソースデータベースのバイナリコピーである必要があります。つまり、ターゲットはストリーミングレプリケーションの一部であるか、pg_basebackupコマンドを使用してソースから作成されたPostgreSQLインスタンスである必要があります。ソースデータベースの論理ダンプから作成されたデータベースは、ホワイトリストファイルをインポートできません。このような場合、ホワイトリストを手動で構成する必要があります。

    ステップ2：ユーザーのホワイトリストを有効にする

    SQLファイアウォール機能についていくつかのアイデアが得られたので、pagilaデータベースとchinookデータベースのhuman_userとapp_userの両方のホワイトリスト登録プロセスを開始しましょう。

    以下のコードスニペットでは、postgresスーパーユーザーとして次のコマンドを実行しています。

    postgres=# \connect pagila
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');\
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# \connect chinook
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

    sqlfirewall_whitelist_users（）関数を実行して確認することもできます。

    $ psql -U postgres -d pagila -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"
Password for user postgres:
 sqlfirewall_whitelist_users
-----------------------------
 (17479,human_user,RECORD)
 (17480,app_user,RECORD)
(2 rows)

$ psql -U postgres -d chinook -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"
Password for user postgres:
 sqlfirewall_whitelist_users
-----------------------------
 (17479,human_user,RECORD)
 (17480,app_user,RECORD)
(2 rows)

    ステップ3：ワークロードの実行

    ホワイトリストを有効にして記録した状態で、app_userアカウントに切り替えて、以下に示すようにいくつかのクエリを実行します。 app_userがさまざまなテーブルからさまざまな「IDフィールド」（customer_id、staff_id、EmployeeIDなど）を選択していることに注目してください。

    postgres=# \c - app_user
Password for user app_user:
You are now connected to database "postgres" as user "app_user".
postgres=> \connect pagila
You are now connected to database "pagila" as user "app_user".
pagila=> SELECT customer_id, first_name, last_name, email FROM public.customer;
...
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
...
pagila=> SELECT staff_id, first_name, last_name, email FROM public.staff;
...
pagila=> \connect chinook;
You are now connected to database "chinook" as user "app_user".
chinook=> SELECT "CustomerId", "FirstName", "LastName", "Phone" FROM public."Customer";
...
chinook=> SELECT "EmployeeId", "FirstName", "LastName", "Phone", "Email" FROM public."Employee";
...

    次に、human_userアカウントに切り替えて、app_userがアクセスしたいくつかのテーブルに対していくつかの簡単なクエリを実行します。

    postgres=# \c - human_user
Password for user human_user:
You are now connected to database "postgres" as user "human_user".
postgres=> \connect pagila;
You are now connected to database "pagila" as user "human_user".
pagila=> SELECT payment_date, amount FROM public.payment;
...
pagila=> SELECT first_name, last_name, email FROM public.customer;
...
pagila=> \connect chinook;
You are now connected to database "chinook" as user "human_user".
chinook=> SELECT "FirstName", "LastName", "Phone", "Email" FROM public."Employee";
...

    いずれかのデータベースからpostgresユーザーとしてsqlfirewallビューにクエリを実行すると、ユーザーごとにホワイトリストに登録されたクエリを確認できます。

    ステップ4：ホワイトリストの適用

    サンプルワークロードがキャプチャされたので、次のコマンドを実行して、両方のデータベースの両方のユーザーアカウントにホワイトリストを適用します。コマンドはスーパーユーザーが実行する必要があります。この場合、これらをユーザーpostgresとして実行しています。

    postgres=# \connect pagila;
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# \connect chinook;
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

    ステップ5：テスト

    ホワイトリストをテストするために、human_userとしてpagilaデータベースにログインし、以前に実行されたコマンドを実行しようとしました

    chinook=# \c - human_user;
Password for user human_user:
You are now connected to database "chinook" as user "human_user".
chinook=> \connect pagila;
You are now connected to database "pagila" as user "human_user".

pagila=> SELECT payment_date, amount FROM public.payment;
...
pagila=> SELECT first_name, last_name, email FROM public.customer;
...

    コマンドは成功します。これは、これらのコマンドが以前にhuman_userによって実行され、ホワイトリストに登録されていたためです。

    次に、次のコマンドを実行してみます。 human_userが2つの追加フィールドを使用してクエリを実行しようとしていることに注意してください。このクエリは以前にapp_userによって実行されました。

    pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;

    ステートメントは次のようなメッセージで失敗します：

    ERROR:  Execution of non-whitelisted statement prohibited

    これは、human_userが以前にコマンドを実行して、現在アクセスしようとしている追加のフィールド（支払いIDと顧客ID）ではなく、このテーブルから2つのフィールドのみを選択したために発生しています。 SQLファイアウォールは、以前のクエリを既知のワークロードとして記録し、そのクエリをホワイトリストに登録しました。彼がクエリにこれらの2つの新しいフィールドを追加しようとすると、ファイアウォールが彼をブロックしています。

    あなたがそれについて考えるならば、これはハッカーがIDフィールド値を盗むことを望むかもしれない方法であり、それはさらなる情報を得るために別のクエリのWHERE句で使用されることができます。ホワイトリスト方式を使用すると、それを効果的にブロックできます。

    では、ユーザーが正当な目的でこれら2つの追加フィールドを必要とする場合はどうなりますか？このような場合、新しいクエリを実行し、SQLファイアウォールがそれらをホワイトリストに登録できるように、ユーザーのホワイトリストモードを再度「RECORD」に戻す必要があります。

    まとめる前に、別のテストを実行してみましょう。今回は、ハッカーがapp_userアカウントを侵害し、「支払い」テーブルに対して削除ステートメントを実行したいと想定します。テーブルに対するユーザーにDELETEおよびTRUNCATE権限を付与したことを思い出してください。

    したがって、app_userとしてログインし、DELETEステートメントを実行します。

    pagila=> \c - app_user
Password for user app_user:
You are now connected to database "pagila" as user "app_user".
pagila=> DELETE FROM public.payment;
ERROR:  Execution of non-whitelisted statement prohibited

    結論

    ホワイトリストに登録されていないため、ステートメントは拒否されます。ユーザーがテーブルからデータを削除する権利を持っている場合でも、SQLファイアウォールはデータを正しくブロックしています。

    ご覧のとおり、SQLファイアウォールは強力なセキュリティツールです。疑似プロダクションモードで使用できるようにする安全機能があります。このモードでは、ステートメントをホワイトリストに登録するようにテストユーザーを構成してから、機能をテストできます。

    ただし、DBAとシステム管理者は、いくつかの点に注意する必要があります。

    まず、ユーザーのホワイトリストモードが「RECORD」に設定されている場合、SQLファイアウォールはユーザーによるクエリの実行を停止しません。つまり、SQLファイアウォールは、ユーザーをブロックする前に最初にトレーニングする必要があります。そのため、通常のデータベースアクセス権限がすべてのユーザーアカウントにも適用されるようにすることが重要です。スーパーユーザーとsqlfirewall_managerの役割のメンバーはファイアウォールのルールから除外されるため、これはさらに重要です。 SQLファイアウォールは、既存のデータベースセキュリティに代わるものではなく、それを補完するものです。

    次に、個々のSELECT、INSERT、UPDATE、およびDELETEステートメントをホワイトリストに登録する場合、SQLファイアウォールは、異なる大文字と小文字（大文字、大文字と小文字の混合、または小文字）で記述されたこれらのコマンドで使用されるオブジェクト名を同じものとして扱います。他のすべてのコマンドは、テキストのクエリ文字列に基づいて比較されます。したがって、たとえば、SQLファイアウォールは「BEGIN」と「begin」と「Begin」を別々のクエリの一部として扱います。

    第3に、SQLファイアウォールのホワイトリストは、レプリケーション環境のスタンバイノードに自動的にレプリケートされません。ただし、sqlfirewall_whitelist_export関数を使用してホワイトリストをエクスポートし、sqlfirewall_whitelist_import関数を使用して別のサーバーにインポートすることができます。残念ながら、データベースまたはsqlfirewallスキーマをバックアップし、ターゲットインスタンスで復元することはできません。また、ホワイトリストを使用するには、ターゲットサーバーに同じユーザーアカウントが存在する必要があります。

    ユーザーがデータベースに対して実行できるすべての可能なタイプのクエリを慎重に検討し、すべての通常のワークロードをキャプチャするために必要な限り、「RECORD」モードでホワイトリストを実行する必要があります。キャプチャが少なすぎると、ユーザーアカウントが正当なクエリを実行できなくなる可能性がありますが、記録が長すぎると、ホワイトリストにコマンドが不必要に追加される可能性があります。これにより、SQLファイアウォールが強制モードでステートメントを比較するときに遅延が発生する可能性があります。


    1. MariaDBでのUPPER（）のしくみ

    2. 結合されたテーブル列の個別の合計を取得します

    3. 行の値を連結するT-SQL

    4. MariaDBの保存データの暗号化に関する考慮事項