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

数多のセキュリティリスクを抱えた 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の障害が発生すると利用できない • 自前のスクリプトを実行したり、若干手間が増えた

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

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

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

Kyohei Kushihara

Other Decks in Technology

Featured

Transcript