安全安心なRDSへの接続方法

Transcript

1. 安心安全なRDSへの接続方法 踏み台サーバからの脱却を目指して
2. アジェンダ 01 現状の課題 踏み台サーバ方式が抱えるセキュリティ・運用上の問題点 02 今回目指すこと 現状の改善目標 03 全体アーキテクチャ図 最終成果物 04 定量的な比較 コスト・セキュリティ・運用負荷の比較 05 結論・今回詰まったポイント PoC で確認できた成果と今後の展開
3. 01｜現状の課題 踏み台サーバ使ってますか？
4. 01｜現状の課題 特定のサーバへアクセスするために中継役として設置されるサーバ 踏み台サーバとは・・・ 1.セキュリティリスクの増加 2.管理負荷の増加 3.導入コスト 主なリスク・・・
5. 01｜現状の課題 Private Sub上のRDSへの接続は踏み台サーバが活用されていることが多く、セキュリティ・コスト面において課題が見られる。 踏み台 WEB WEB AP DB AP EC2 RDS EC2 EC2 EC2 EC2 ①依頼 ②承認 ③接続 開発者 アーキテクチャ図 課題 VPN 検証 上司 課題 1｜申請フローが完全に属人化 課題 2｜踏み台用EC2の管理コスト 課題 3｜Pub Sub 上EC2のリスク *一般的な三層構造を例示
6. 02｜今回目指すこと 現行アーキテクチャを承認フローと接続フローに分割、それぞれの課題の解決を目指す。 踏み台 WEB WEB AP DB AP EC2 RDS EC2 EC2 EC2 EC2 ①依頼 ②承認 ③接続 開発者 目標 VPN 検証 上司 目標 1｜申請フローを維持したまま、属人化しない方 法に移行 *一般的な三層構造を例示 承認フロー 接続フロー 目標 2｜踏み台サーバを廃止し、同等以上のセキュリ ティを実現
7. 03｜全体アーキテクチャ図（TO-BE 接続フロー） 新構成：SSM Session Managerを使用してPrivate SubのEC2に接続、EC2内のポートフォワーディングを活用してRDSまで到達させる。 AWS System Managerを使用してPrivate Subnet内の EC2に接続できるようにした。 EC2内のHA Proxyを利用して、RDSへ接続を到達させる。 上記構成により、一度のPrivate Subを経由させることなくRDS へ接続することが可能になった。 開発者 踏み台の完全廃止に成功！
8. 03｜全体アーキテクチャ図（TO-BE 承認フロー） 新構成：サーバレスアーキテクチャで承認フローを再構成した。 ・依頼 開発者はS3でホスティングしたHTMLより、接続申請を提 出する。 API Gateway経由でLambdaが反応し、SESから上司 に通知メールが飛ぶ。 ・承認 上司は依頼内容を確認し、問題なければ承認を押下する。 LambdaがSSMより認証キーを取得し、SES経由で開発 者に接続のための認証キーを提供する。 開発者 上司 ①依頼 ②承認 S3 API Gateway System Manager Lambda Dynamo SES
9. 03｜実際の画面 申請フローの改修では、実際にメールで認証情報が届くことを確認した。 S3に配置したログイン申請 管理者宛てに届いたメール 承認時のメール
10. 03｜実際の画面 接続フローの改修では、SSM SessionManager接続を確立することで、RDSへ接続できることを確認した。 SSMトンネル未開通 SSMトンネル開通済み
11. 04｜定量的な比較 コスト・セキュリティ・運用負荷のすべての観点で現状を上回る結果となった ▪ コスト比較（東京リージョン・オンデマンド概算） 項目 AS-IS（現状） TO-BE（新構成） 差分 EC2 インスタンス m5.large / Windows Server ≈ $0.192/h 既存のサーバを流用するので$0 ▲ 約 100% SSM / VPN コスト VPN （OS コストに含む） SSM VPC Endpoint × 3 ≈ $0.084/h 新規コスト 月額概算 ≈ $138 / 月 ≈ $80 / 月 ▲ $58 / 月 年額概算 ≈ $1,660 / 年 （≈ ¥240,000） ≈ $960 / 年 （≈ ¥139,000） ▲ $700 / 年 （▲ 42%） ▪ セキュリティ・運用比較 観点 AS-IS TO-BE 評価 VPN 要否 必要（毎日パスワード更新） 不要（HTTPS のみ） ◦ 踏み台配置 パブリックサブネット 廃止（EC2はプライベート） ◦ 接続承認 メール手動（管理者が毎日） 1クリック自動承認 ◦
12. 05｜結論・苦戦した点 PoCにより実現性を確認。本番適用に向けた具体的な課題と展開方針を整理した 「踏み台サーバ + VPN」から「SSM Session Manager + 承認フロー」への移行により、セキュリティ強化・運用自動化・コスト削減を同時に実現できることを確認した 確認できたこと ・VPN なし・踏み台なしで Oracle RDS への接続を実証 ・SQL Developer / SQL*Plus 両方での動作確認 ・管理者が承認しない限り接続コマンドが発行されない制御の実装 ・SSM セッションログで誰がいつ接続したか記録可能 ・AWS の仕様（ロールチェーン最大1時間）により接続時間の自動制限 苦戦したポイント PoC 費用：約 200 円（数時間のテスト分のみ） | 本番適用後の年間削減効果：約 ¥100,000（▲42%） | かつセキュリティ・監査対応力が向上 ・SSMエンドポイントを作成する際は、enableDnsHostnamesを有効にしないと失敗する。 ・SSMエンドポイントは以下の3つを作成しないと接続できない。 ssm : SSMのメイン制御 ssmmessages : セッションマネージャーとの通信経路 ec2messages : EC2インスタンスとの通信 ・HA ProxyをPrivate Sub上のEC2にインストールする場合は、S3 Gateway Endpoint かNATゲートウェイが必要（NATは高額なのでS3が良いと思う）