著者:takahashi
PostgreSQL “対向(peer)認証に失敗しました” エラーが出るときの対処法
PostgreSQLでちゃんとユーザーにログイン権限とパスワードを設定しているのに、
psql: FATAL: ユーザ "postgres" で対向(peer)認証に失敗しました
のようなエラーが出てしまった場合の対処法です。
そもそもPeer認証とは
CentOS6でPostgreSQLインストール – My Octopress Blog
Peer認証とは、カーネルからクライアント上のシステムユーザ名を取得し、PostgreSQLデータベースユーザと同一である場合のみ接続が許可される仕組みです。
つまり、Postgresql内のユーザーとUNIXユーザで、ユーザー名が一致してさえいれば認証情報なしでログイン出来てしまう仕組みです。
パスワードを打たなくてもいいのは楽ですが、例えばユーザーごとに権限を変えて置いて、場合によって使い分けたいときや一時的に別のpsqlユーザーとしてログインしたいときなどはかなりやりづらいですし、psql側でユーザーを作る際に、同名のUNIXユーザーも追加する必要が出てくるのでとてもめんどくさいです。
この挙動を変更するには、pg_hba.conf （だいたいpsqlのデータフォルダか/etcにあるはずです。）を編集します。
ファイルを開くと
#ローカルで動いているpsqlへアクセスする場合 local all all peer #他のクライアントからpsqlへアクセス可能にする場合(例) host all all 127.0.0.1/32 peer
などとなっているか、あるいはコメントアウトされているかと思いますので、これを書き換えます。
#ローカルで動いているpsqlへアクセスする場合 local all all md5 #他のクライアントからpsqlへアクセス可能にする場合(例) host all all 127.0.0.1/32 md5
パスワード認証させたい場合は”peer”の部分を”md5″に変更して保存し、psqlのデーモンを再起動させます。
これで再度ログインを行えば、今度はパスワードを求められ、正しい情報を入力すればどのユーザーでもログインできるようになるかと思います。
著者:takahashi
MariaDBでDBをテーブル単位で暗号化する方法
最近、何かと情報流出のニュースって多いですよね。
基本的にはサーバに不正侵入させないのが第一ではあるのですが、攻撃が巧妙化してくると、なかなか簡単には防御できないこともあり得ます。
そういう場合も想定して、万が一サーバに第三者が不正に侵入してきたときの保険として、データそのものを暗号化してしまう方法があります。
Webサービスなどでは、データの保存先としてよくデータベースを利用しますが、最近このDBエンジン自体が暗号化機能を持っているものが出てきました。
今回はMariaDBというMySQL互換のDBエンジンで暗号化設定をしてみました。
(使用OS:CentOS 7)
まずはmariaDBをインストールします。
mariaDB自体はCentOSのepelリポジトリにも存在しているのですが、実はepel版MariaDBはバージョン5系のものとなっており、暗号化がサポートされるのが10.1からとなっています。
そのため、公式リポジトリのMariaDBでは暗号化することができません。
バージョン10.1以上のMariaDBはMariaDB公式のリポジトリから入手できるので、今回はこちらを使います。
折角なら最新版をということで、現時点の安定板の最新版 v10.3 をインストールします。
sudo vi /etc/yum.repos.d/mariadb.repo
などどして、下記の内容でMariadbのリポジトリファイルを作成します。
# MariaDB 10.3 CentOS repository list - created 2018-07-04 11:06 UTC # http://downloads.mariadb.org/mariadb/repositories/ [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.3/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
ファイルを作成したらyumでmariadbをインストールします。
#MariaDBをインストール sudo yum install MariaDB-server MariaDB-client
MariaDBを立ち上げる前に、暗号化の設定を先に行っておきます。
まずは暗号化に使うキーを生成します。
openssl enc -aes-256-cbc -k パスワード -P -md sha1
下記のような内容が表示されます。
salt=英数字 key=英数字 iv =英数字
新しくファイルを作成し、表示された英数字を次のように記載します。
暗号化・復号化する際の鍵番号(1以上の数字を任意に指定);ivの値;keyの値
鍵ファイルを暗号化します。
openssl enc -aes-256-cbc -md sha1 -k パスワード2 -in 先程つくった鍵ファイルのパス -out 暗号化後ファイルの保存先
/etc/my.cnf.d/server.cnf
を管理者権限で開き、[mysqld]セクションのすぐ下に、下記の設定を追記します。
plugin-load-add=file_key_management.so file_key_management file_key_management_filename = 先程作成した鍵ファイルのパス file_key_management_filekey = 鍵ファイルにかけたパスワード file_key_management_encryption_algorithm=AES_CBC
これで準備ができたので、早速MariaDBを立ち上げます。
sudo systemctl start mariadb #mariadb起動 sudo systemctl enable mariadb #mariadbの自動起動を有効化
これで暗号化が有効になったはずです。
それでは早速、暗号化されたテーブルを作ってみます。
CREATE DATABASE hoge; use hoge; CREATE TABLE test (id INT) ENCRYPTED=YES ENCRYPTION_KEY_ID=先程の鍵に指定した鍵id;
テーブルにデータを入れます。
#例 INSERT INTO hoge(id) VALUES (1);
この状態でselectをかけると通常通りデータが出力されますが、最初に編集した
/etc/my.cnf.d/server.cnf
の今回の変更部分をすべてコメントアウトした状態でmariaDBを再起動、再びhogeテーブルをSELECTすると…
ERROR 1932 (42S02): Table 'hoge.test' doesn't exist in engine
のように表示され、中のデータが見れなくなっていることがわかるかと思います。
このようにしておけば、MariaDBのデータ本体を抜かれても、キーファイルが漏れていても、そのパスワードが漏れなければデータの中身を見られる心配はありません。
ただし、/etc/my.cnf.d/server.cnfにパスワードを直書きしてしまっているので、このファイルを漏れないように気を配る必要はありそうです。
今回のMariaDBのように、暗号化する仕組みをはじめから備えていて、簡単に設定できる環境も増えてきています。
これからもし情報が洩れてはいけないようなサービスを作ろうと考えられている方がいましたら、是非参考になれば幸いです。