RDSクエリエディタでパスワード漏洩に注意

AWS RDS/Aurora Secrets Manager

AWSコンソールでRDSのクエリエディタを使用していた際に、「知らないで運用していたら危ないな」と思い記事にしてみました。


まとめ

RDS クエリエディタ上でDBユーザのユーザー名・パスワードを入力してDBにアクセスすると、そのユーザのユーザー名・パスワードを含むシークレットがSecrets Managerに作成されます。


そのシークレットには特にリソースポリシーなどは設定されておらず、Secrets Managerへのアクセス権限ポリシーを持つIAMユーザ・ロールであれば、作成されたユーザーの認証情報（パスワード含む）を閲覧できてします。


※Aurora Serverless v2が最近の流行かと思いますが、今回のクエリエディタはAurora Serverless v1が対象の機能になります。


RDS クエリエディタ

RDS クエリエディタとは、Aurora Serverless v1で構築されたDBにAWSコンソール上からアクセスして、SQLクエリを発行したりすることができる便利な機能です。

特にプライベートサブネットに作ることが多いRDBにアクセスするには踏み台サーバーが必要だったり、Data APIを用いたスクリプトでアクセスするためにコーディングしたりと手間がかかるため、気軽にアクセスすることができるのは非常に楽です。


一連の流れ

RDS クエリエディタからデータベース接続する流れ・そして上記で挙げたSecrets Managerのシークレット作成までを確認してみます。


データベースに接続

RDSのコンソールに行き、左メニューから「クエリエディタ」を選択します。


すると以下のような画面が出てきます。


ここで、「データベースインスタンスまたはクラスター」で接続先を選択します。

そして「データベースユーザー名」で「新しいデータベース認証情報を追加します」を選択し、ユーザー名・パスワードを入力して右下の接続ボタンを押下するとログインができます。


シークレット作成

上記の流れでログインできるようになると、Secrets Managerに該当ユーザの認証情報を含むシークレットが作成されます。


Secrets Managerのリスト画面から該当シークレットを選択し、「シークレットの値」で「シークレットの値を取得する」を押してみると、このように認証情報が格納されています。


また、「リソースのアクセス許可」にて該当シークレットのリソースポリシーが確認できますが、特に制限などはついていません。

つまり、Secrets Managerへのアクセス権限ポリシーを持つIAMユーザ・ロールであれば、こちらのシークレット、つまり作成されたユーザーの認証情報（パスワード含む）を閲覧できてします。


注意

決してクエリエディタという機能が悪い・ダメだという話ではありません！！

さらに言えば、シークレット(Secrets Manager)とは認証情報などを格納するものなので今回の話はクエリエディタに限る話ではないのですが、知らずに運用してしまいがちな部分だと思ったため今回記事としてまとめてみました。


前提

今更前提のお話なのですが、今回は以下のような環境が前提となっています。

  • IAM環境が緩いAWS環境
  • DBユーザーをちゃんと各人員ごとに用意している


前者の「IAM環境が緩いAWS環境」ですが、やはり開発環境などだとIAMのポリシー管理が緩くなりがちなところがあります。

また今回のケースは、動的にIAMユーザのアクションに応じて自動生成されるシークレットなので、最初からIAMユーザのポリシーで他のユーザのシークレットの閲覧を拒否するには、IAMとDBユーザの命名規則を揃えたりなどのハードルがあり、なかなか大変です。


後者の「DBユーザーをちゃんと各人員ごとに用意している」ですが、環境によっては一つのDBユーザを全オペレーターで使いまわしているケースもあるかもしれません。

その場合は今回の問題は該当しないかとは思われます。。

しかしそれはそれでユーザの共有は、怪しいアクセスであったり何か問題が発生したとき、誰がそれを行なったかの特定がしづらいため、運用上お勧めしません。


防止方法

今回の防止方法をいくつか考えてみました。


ポリシー管理で防御

ちょっと大変なのですが、上記で少し話した、他のユーザのシークレットにアクセスできなくする方法です。

運用ルールとして、DBユーザー名とIAMユーザー名を揃えるようにしておき、IAMポリシーにはConditionルールとして自分の名前を含まないシークレットへのアクセスを拒否させます。


ただしこれは、命名規則に漏れがあったり、アプリケーションで使用するDBユーザのシークレットにもアクセスできなかったりと、中々苦しい点がありそうなのであまり詳しくは書きません。

うまく運用の仕組みが作れれば、OrganizationsのSCPで予めポリシー制限をしたり、 CloudTrailで検知したりなど、ある程度いい感じにできそうですね。


他にも、AWS Configでカスタムルールを作成し、シークレットが作成されたらそのシークレットに動的にリソースポリシーをつけるとか、IAMユーザに動的に拒否ポリシーつけるとか、色々方法があるかもしれません。


クエリエディタを使用しない

こちらはシンプルです。クエリエディタ以外の方法でDBにアクセスするようにします。

提供される機能を使用しないというのはできれば行いたくない選択ですが、、、


具体的にはEC2やECS・Fargate等で踏み台サーバを作成し、サーバに入ってDBにアクセスしたり、またSSHポートフォワード（トンネリング）で踏み台サーバを経由して透過的にローカル環境からアクセスするような方法です。

この場合、SSMのセッションマネージャーという機能を使うと、安全にSSHアクセスやポートフォワーディングすることが可能なのでオススメです。


またローカルPCのターミナル等から直接DBにアクセスしたい場合、SSL VPNを使用する方法もあります。

特にAWSのClient VPNを使用すれば、VPNサーバなどを用意せず比較的楽にVPN環境を構築・運用することが可能です。


最後に

この機能を使っている方がどれくらいいるかわかりませんが、何かの気付きになりましたら幸いです。