数多のセキュリティリスクを抱えた DBを改善した話 

自己紹介 ● 櫛原(くしはら) 京平 ● インフラ（クラウド） ● AWS/GCP/Alibaba ● 好きなAWSサービス ○ Step Functions 

ローカル->DBへの接続、どうしてますか ● DBへの接続経路は？ ○ SSH鍵を利用して踏み台サーバを経由して接続 ○ Session Managerを利用して踏み台サーバを経由して接続 ● DB接続方法は？ ○ パスワード認証を利用して接続 ○ IAMデータベース認証を利用して接続 …etc 

弊社のこれまでの接続方法 SSH鍵接続を利用して 弊社の接続方式は「エジパパ 方式」でした ※こんな方式名はでないので本日限りで忘れてください 常時起動している パブリックサブネットの踏み台サーバから パスワード認証を利用して DB接続を行っていた 

エジパパ方式の欠点 ● SSH鍵を利用しており漏洩リスクがある ○ 22番ポートを解放している ● 常時インターネットから接続できる経路がある ● DBパスワードの漏洩リスクがある ● DB接続情報所有者がサイレントにDB接続できる 

このLTで伝えたいこと （特にレガシーシステム） 前述したDB接続のセキュリティリスクを緩和し、 DBに格納されている情報が抜かれにくいインフラを目指して 弊社が採用した方式を聞いてください！！ そして、世に存在しているエジパパを解放したい 

目次 ● 採用した接続方法 ● 実際の運用方法 ● インフラ構成について ● この方式を実際に利用してみて 

採用した接続方法 

弊社の接続方式 Session Managerを利用して、 必要な時に起動する プライベートサブネットの踏み台サーバから パスワード認証を利用して ← 運用起因 DB接続を行う DBパスワード認証を利用したのは、 SREチームで利用している MySQL GUIクライアントツールが IAM認証に未対応であったため 

エジパパ方式と比較したメリット ● SSH鍵が不要 ○ 22番ポートを解放する必要がない ● 踏み台サーバがインターネットに常時晒されない ● 踏み台サーバの利用履歴がSlack上に残る 

具体的な使用方法について 

踏み台の起動① Slackから踏み台を起動 ● 対象のプロジェクト ● 必要な権限 ● 対象者 提示されたコマンドを ローカルPCで実行する 

SSM ポートフォワード② 自作のスクリプトによって、 Session Managerを利用したポートフォワードを行う ※この状態でローカルPCとAuroraが疎通できる状況 

コマンドの裏側 内部的に下記のようなコマンドを実行し、ポートフォワードを行う aws ssm start-session --target "$instance_id" \ --document-name AWS-StartPortForwardingSessionToRemoteHost \ --parameters "{\"host\":[\"$rds_endpoint\"],\"portNumber\":[\"3306\"],\"localPortNumber\":[\"3306\"]}" 

DBとの接続を確立③ 

インフラ構成について 

インフラ構成 ● Slack ● Lambda ● Step Functions ○ 権限付与 ○ ユーザー管理 ○ サーバ作成・終了 

この方式を実際に利用してみて 

メリット ● 誰がどんな権限でDB接続しているのか明瞭になった ● 踏み台サーバへの経路がほぼ絶たれた安心感 ● 常時 DBへの書き込み権限を所有しているユーザーが減った 

デメリット ● Slack or AWSの障害が発生すると利用できない ● 自前のスクリプトを実行したり、若干手間が増えた 

● ぜひ これを機に確認してみてください ● システムで解決したり、 運用でカバーしている などあると思います この後の懇親会で、（話せる範囲で）運用方法を教えてください！ 皆さんの接続方式はなんですか？