WebシステムがPostgreSQLにアクセスするときのDBロールはどうしていますか？ postgres みたいな全能ロールをそのまま使う⋯⋯ でも動くシステムにはできるんですが、仮にアプリサーバ側の脆弱性を突かれたときに即DBの全権限まで危険にさらされる構成はインターネットにさらす本番システムではやりにくく、SELECT/INSERT/UPDATE/DELET権限だけ付けたデータアクセス専用のロールを作ってこれを使うのが一般的かと思います。
すると手間になってくるのがテーブルを追加したときにGRANTが必要なことですし、それをうっかり忘れて本番リリース後に権限エラー発生みたいな事故も起こりえます。
本日も超小物のお題をお送りします、エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]です。
新規テーブルができたら自動でアプリ用ロールに権限を付ける
PostgreSQLにはちゃんと、今後作られるテーブルがあったとき誰にどんな権限を付けるかというのをあらかじめ決めておける機能があります。
ALTER DEFAULT PRIVILEGESコマンドです（ドキュメント ）。
これを使うと、例えばアプリ用のロールが my_app で、利用するスキーマが pubilc だったら、次のように書けば今後の新規テーブルへもR/W権限*1を持てるようになります。
-- 問い合わせ・DMLをすべて許可 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO my_app; -- シーケンスを使った自動採番INSERTを許可 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE ON SEQUENCES TO my_app;
これで毎回GRANTを忘れず発行せねばという注意力ポイントを一個減らせますね！
We are hiring
私達エムスリーのエンジニアは決してみんな「フルスタック」な万能プレイヤーではありません。それぞれが各々のスペシャリティの中でお仕事をしています。
でもそれは、開発エンジニアがインフラや操作運用やデータ分析のことを考えていないということではなく、お互いの仕事がやりやすくなるような一手を考え合い提案しあっている世界です。今回のもマイグレーションを書くアプリエンジニアと適用するDBAとの間でポケットに落ちそうな注意点を必要性ごとなくしてしまう一アイデアでした。
スペシャリスト同士で有機的に協力できるエンジニアリング環境、ちょっとでもご興味ありましたらこちらのページからどうぞ。応募を前提にしないカジュアル面談もやっています。
*1:TRUNCATEコマンドも使うとかトリガーなり関数も使うとかあればそれらの記述も追加してください
