kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言

tl;dr

  • Site to Site VPN, Direct Connect, Client VPNなどでオフィスネットワークとVPCがつながっていない前提
  • 従来Bastionインスタンスをおいていたがモダンな設計ではもはやRDS以外で使われない
  • publicly accessibleがtrueでもセキュリティを担保しやすくなっておりメリットも多いのでそうしたらどうだろうか

BastionがもはやEC2インスタンス用でいらない背景

elpy1/ssh-over-ssmやEC2 instance connect, そもそもECSやEKSの場合は個別のノードへログインする必要性がない、などの背景でモダンなAWSアーキテクチャではEC2インスタンスへのログインのためにbastionはほぼほぼ不要になりつつある。

bastionを使うとbastionに秘密鍵をおいてしまったり退職者のユーザーアカウントがなかなか削除されなかったりいつの間にかそこからデプロイされるようになる = immutableではなくなり作り直しができなくなる、などの問題があるためむしろ積極的に避けたい。

public accessibleをtrueにする利点

  • メリット
    • 設計がシンプル
      • RDSを知っている人なら誰でも接続方法がわかる
      • 部署やシステムごとに接続方法が変わったりしない
        • 接続方法のドキュメントをメンテナンスしたりその場所を考慮したりする必要がない
    • 余計な経路がないので可用性が高まる
      • bastionの可用性を担保しようとすると冗長化などでかなり構成が複雑になる
    • bastionで余計なコストが掛からない
    • mysqlクライアントから接続するときにssh port forwardingなどの設定が不要
      • 設定が難解で動作確認も難しいので非エンジニアにもやってもらうのがキビシイ
    • ssh port forwardingやbastionサーバをサポートしていないmysqlクライアントでも接続可能

publicly accessibleを有効にするリスクは幽霊では?

RDSでpublicly accessibleがtrueであることがセキュリティリスクである、ということはAWSを使う者にとってある程度の共通認識である。 しかし、これがどうにも疑わしい。 bastionを経由しようが結局public IPアドレスが振られるのがRDSインスタンスからbastionへ変わっただけで実態的なセキュリティリスクは減っていない。 確かにMySQLなどはプロトコルがセキュアでなかったりsshより比較的簡単なIDパスワードが使われる傾向がある。しかしIAMデータベース認証ではセキュアプロトコルが強制されるしセキュリティグループなどで接続元を絞れば十分安全である。またパスワードはそもそも十分セキュアな文字列にするべきだ。

これは個人的な推測なのだがどうにもpublicly accessible有効が危険だという認識は極めてずさんな設定のRDSへ攻撃された事例や話から生まれている気がする。実際の事例を聞くと安易にpublicly accessibleを有効にしたRDSインスタンスでsecureでないrootアカウントを設定してrootアカウントのユーザー名も"root"のままにしていたような、そのような話しかない。 確かにpublicly accessibleをfalseにすれば攻撃の難易度は上がるがDBインスタンスへのアクセシビリティを犠牲にしているので一概にやるべきとは思えない。

上記を踏まえてのpublicly accessible: trueでのおすすめ設定

  • (must) publicly accessibleをtrueにする
  • (must) セキュリティグループでingressをオフィスゲートウェイ(+ VPC)に絞る
  • (must) アプリケーション用パスワードは十分セキュアな文字列にする(パスワードジェネレータなど推奨)
  • (must) インターネットを経由する接続には必ずSSLプロトコルを利用する
  • (should) 開発者の接続はIAM データベース認証 - Amazon Auroraを使う
    • 必然的にプロトコルSSLになるためインターネット経由の接続でも通信内容が漏れる心配がない
  • (may) 接続ポートをデフォルトから変える1
    • 安易な攻撃からの防御手段になるがポートスキャンなどで無意味化される。本質的な対策ではないかも。

残タスク

publicly accessibleを有効にした場合、果たしてもはやprivate subnetは必要なのかという疑問が湧いてくる。 現段階ではもはや必要ない気がする2。ここについては追加調査が必要。

2020/06/19 追記

AWSのサポートに本件について問い合わせたところ、Publicly AccessibleのON/OFFとセキュリティについてはどちらとも言えないという返答が返ってきた。 Publicly AccessibleをONにしてもSecurity Groupなどを使えばセキュアにできるし、 Publicly AccessibleをOFFにしても踏み台サーバのセキュリティが弱かったりすればRDSへ侵入される危険があると。 道理だ。


  1. 変える場合は変更先のポート番号などに特にコンベンションなどなさそうなので(TCPやUDPにおけるポート番号の一覧 - Wikipedia)雑だが1万番代のポート番号からランダムで選択などでいいと思う。特にRDSは独立したインスタンスなのでポート番号がかぶる心配はない

  2. GCPとかそもそもVPC概念薄いが運用上問題になる話はほぼない。あっても既存の運用を変えずにGCPへ持っていきたいというケースしか聞かない