Hashi Corp Vaultを使ったDBユーザー管理

ツール導入前の課題

背景

「Chatwork」ではチャットという特性上、秘匿情報を持ったDBテーブルが多く存在します。
そのため、各エンジニアは秘匿情報にアクセスできないようにカラムレベルで権限制御を行っています。
また、監査という観点からもAuditログをしっかりと記録する必要があるため、エンジニア単位でDBユーザーを作成する必要があります。

課題

エンジニア単位での管理は、エンジニアの増加に伴い管理コストも上がっていくため、 gratanというツールを使ってIaC化して管理をしていました。
ただし、ユーザー作成には強い権限が必要な関係から、CI上での実行などが実現できておらず、トイルとなっていました。 また、gratan自体にもいくつか課題がありました。

gratanの課題

1. ユーザー作成(権限付与)時の問題点

• 毎回ユーザー毎にFLUSH PRIVILEGESを実行していた
  • ユーザー数が多いとDBへの負荷が上昇してしまう
  • 本来はGrant文でのユーザー作成、権限付与の場合にはFLUSH PRIVILEGESは不要
• 回避策として、dry-runで生成されたSQLからFLUSH PRIVILEGESを除いて実行する運用になっていた

2. MySQL8.0以降への対応
   • MySQL8.0以降ではCreate Userでのユーザー作成が必須
   • gratanはアーカイブ化されており更新されていない
     • Aurora MySQL V3（MySQL8.0互換）への移行時に利用不可

どのような状態を目指していたか

• SSOと連動した権限管理が出来る
  • 権限付与する際はSSOのグループにメンバーを追加するなどで対応できるようにしたい
• 権限の更新作業が容易であること
  • 最小限の変更作業で対象ユーザー全員の変更ができるようにしたい
• よりセキュアで安全な機構
  • ユーザー作成時にパスワードの受け渡しなど最小限の範囲に留めたい

• IAM認証

改善したかった課題はどれくらい解決されたか

前述したgratanの課題や目指していた状態はすべて実現できました。

どのような成果が得られたか

SSOのグループへの登録、削除だけで権限が付与できるようになったことで以下のような作業をSREで行うことがなくなり、SREがブロッカーにならなくなりました。

• 開発側でデータ操作を行いたい場合、それまでは権限付与の手間からSREが変わりに作業を行っていた
• その作業の際も開発側には立ち会ってもらう必要があるため、同期的に行う必要があり時間調整などする必要があった

監査の観点からログにはどのエンジニアがどの権限でログイン、DB操作をしたかをわかるようにする必要があり、DBユーザー名にはそういった情報を含めるために工夫をする必要があり、この点が地味に苦労しました。

AWS認証でvaultにログインする場合、デフォルトでは AWSReservedSSO_[ロール名]_[ランダム文字列]/[メールアドレス] というような規則の名前がDBユーザー名となります。
このままでは先程言った、どの権限でという部分が満たせない点と単純に長過ぎてわかりにくいという点がありました。

そこでUsername templatingという機能を使うことで対応しました。
これを使い [prefix]-[ユーザー名]-[権限名]-[ランダム文字列]という規則性で実際に作成するDBユーザー名を作成することができました。