・DB接続アカウント情報は「Secrets Manager」で、と言われた
なぜ？
という質問には詳しい回答がなかった。どうやらAWSの代理店（かなんか）から「そっちの方が安全ですよ」とか言われたらしい、という勝手な憶測をしてみた。
確かに現状のシステムでDB接続アカウントはテキストファイルで保持している。
画面HTML等を更新するユーザからは遮断しているが、サーバ側スクリプトはDB接続の際にそのテキストファイルから設定値を読み出すので、たとえばFTPでそのファイルを読み出すスクリプトを設置して実行すれば読み出せてしまう。
「ああ、危ない。なんてことだ！」ってか？
・じゃあ「Secrets Manager」はめっちゃ安全なの？
一般的なサイトで「Secrets Manager」を導入する場合、たいていはSDKを使って「Secrets Manager」から秘匿情報を読み出して使用する。
1) 「Secrets Manager」からSDKでDB接続アカウント情報を読み出す
2) それを使ってサーバ側スクリプトでDB接続を実行する
何のことはない。従来は情報参照先がローカルファイルだったものが「Secrets Manager」に変化しただけである。
なので「Secrets Manager」に格納したとしてもそこから読み出すスクリプトを設置すれば読めてしまうので、リスクレベル的に向上したとは言えない。
ちょっと悪人の手間が増えるだけ。
でも無知な自分の認識が根本的に間違ってるかもしれない。と思って、上のひとに聞いてみた。
「聞くはいっときの恥」。
・秘匿情報の管理、自動ローテーション、バージョン管理、レプリケーション、詳細ログ、、、モゴモゴ
本人もよく理解できていない様子。
「情報が漏れた時の犯人探しが容易になる」とかは意味不明。
確かに「Secrets Manager」をRDSさせると自動ローテーションにも対応してくれる。らしい。
でもどうだ。結構な台数のうちのサーバで過去にバージョンアップ以外でDB接続アカウントを更新したものがあったか？
少なくとも自分が担当してから結構な年月が経つが、いちどもローテーションしたことはないぞ。
「自動ローテーション」やるとしたらキャッシュミス時の再取得とかで遅延も増大するし。
そもそもいまの構成でも各サイトごとにそれぞれの専用RDSが割り当ててあって、他のホストからの接続は遮断するような構成になってるわけで、なんなら「localhost」並みに接続アカウントすら不要なんじゃないかと思うのだが。
・じゃあ「Secrets Manager」は不要なの？
違う違う、そうじゃ、そうじゃなぁい。
中途半端な実装は役に立たないのでコストの無駄、と言いたいだけ。
本当に接続アカウントを秘匿したければ「Secrets Manager + Secrets Manager Agent」で構築すればサーバ側スクリプトに秘匿情報が漏れることはない。
IAMの一時トークンとかで「よしなに」処理してくれる。
まあそうなんだけど、そこまでの実装が必要か？？？
極論だけど、たとえば接続アカウントが漏洩したとして、それがなにか？
DB側では特定のホストからしか接続を受け付けないようにしてあるし、悪者がその情報を入手したところでうちのサーバにスクリプトを設置してそのアカウントでDBからデータを盗み出す、って、それなら別にわざわざ接続情報を盗まなくてもDBデータ抽出スクリプト書いて設置するだけで実行可能だし。
いまどき公開DB使って個人情報扱うサイトを運用するような尊いサイトってあるのかな。
・自分なりの結論
正直、よく分からんけどいまのことろ懐疑的。
特にうちくらいの構成ではサーバがどんどん重くなるだけな気がする。
まあ、予算使わんといかんのなら止めはせんが。
「監査」とか「セキュリティ」とか、そういう部門に長く居る人たちが苦手。
タイトルに関係ないけど。
