Slide 1

Slide 1 text

HashiCorp Vaultを使った セキュアなDBアクセスの実現 横山達男(@tatsuo4848) | 2021/03/20

Slide 2

Slide 2 text

本セッションのターゲット ● RDSのパスワード管理に悩んでいる方 ● HashiCorp Vaultでどんなことができるのか興味がある方

Slide 3

Slide 3 text

小田原にあるHameeから来ました!

Slide 4

Slide 4 text

自己紹介 twitterアカウント:@tatsuo4848 GitHubアカウント:tatsuo48 ~ これまでの経歴 ~ 拝承系SIer(インフラエンジニア、お客様サポート) ⬇ 株式会社みんなのウェディング(インフラエンジニア、SRE) ⬇ Hamee株式会社(SRE、TechLead) 三度の飯よりAWSが好き

Slide 5

Slide 5 text

Hameeについて

Slide 6

Slide 6 text

Hameeについて

Slide 7

Slide 7 text

Hameeについて

Slide 8

Slide 8 text

Next Engineの機能

Slide 9

Slide 9 text

Next Engineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ

Slide 10

Slide 10 text

Next Engineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ AWSで運用中

Slide 11

Slide 11 text

Next Engineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ AWSで運用予定 (さくらインターネットから移行中 ) AWSで運用中

Slide 12

Slide 12 text

Next Engineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ

Slide 13

Slide 13 text

Next Engineのシステム構成(移行完了後) メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ Auroraクラスター

Slide 14

Slide 14 text

メイン機能 Next Engineのシステム構成(移行完了後) Platform API アプリ アプリ アプリ アプリ アプリ アプリ Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター

Slide 15

Slide 15 text

メイン機能 Next Engineのシステム構成(移行完了後) Platform API アプリ アプリ アプリ アプリ アプリ アプリ Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター Auroraクラスター

Slide 16

Slide 16 text

増え続けるDBインスタンスの ユーザ管理をどうする?

Slide 17

Slide 17 text

課題 ● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする? ○ 問い合わせ対応などで開発者ごとのDBユーザ発行は必須!

Slide 18

Slide 18 text

課題 ● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする? ○ 共通ユーザを作成 ■ 定期的なパスワードローテーションが必要 ■ パスワードの安全な共有方法が必要

Slide 19

Slide 19 text

課題 ● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする? ○ 共通ユーザを作成 ■ 定期的なパスワードローテーションが必要 ■ パスワードの安全な共有方法が必要 ○ 開発者ごとにDBユーザを作成 ■ 定期的なパスワードローテーションが必要 ■ 入社、退社時の作業コストが大

Slide 20

Slide 20 text

どちらの手段も一長一短

Slide 21

Slide 21 text

HashiCorp Vaultで解決!

Slide 22

Slide 22 text

HashiCorp Vaultで解決! ● IAM認証情報を元にRDSの期限付きユーザを発行する仕組みを構築 ○ パスワードローテーション不要 ○ パスワード共有方法も考えなくていい ○ 入社退社時にIAMの更新対応は元から必要なので新規コストは発生せず

Slide 23

Slide 23 text

全体構成図

Slide 24

Slide 24 text

HashiCorp Vaultについて

Slide 25

Slide 25 text

HashiCorp Vaultについて ● Terraformで有名なHashiCorp社が開発したプロダクト ● 機密情報管理 ● 以下を行ってくれる ○ 任意の認証基盤(Auth Methods)を使った認証 ○ ポリシー(Policies)に基づき機密情報(Secrets Engines)へのアクセスを認可 ● Dynamic Secretsという動的な機密情報生成の仕組み

Slide 26

Slide 26 text

認証と認可 ● めちゃくちゃわかりやすい記事がありますのでそちらをお読みください ○ 出典:DevelopersIO,よくわかる認証と認可 ○ https://dev.classmethod.jp/articles/authentication-and-authorization/

Slide 27

Slide 27 text

認証と認可 ● めちゃくちゃわかりやすい記事がありますのでそちらをお読みください ○ 出典:DevelopersIO,よくわかる認証と認可 ○ https://dev.classmethod.jp/articles/authentication-and-authorization/ ● 認証は「通信の相手が誰(何)であるかを確認すること」 ● 認可は「とある特定の条件に対して、リソースアクセスの権限を与えること」

Slide 28

Slide 28 text

認証と認可(HashiCorp Vaultの場合)

Slide 29

Slide 29 text

認証と認可(HashiCorp Vaultの場合) 認証は「認証情報を元に、認証基盤に正しい通信相手か確認すること」

Slide 30

Slide 30 text

認証と認可(HashiCorp Vaultの場合) 認証は「認証情報を元に、認証基盤に正しい通信相手か確認すること」 認可は「認証が通ったユーザに、ポリシーに基づいて機密情報へのアクセス権限を与えること」

Slide 31

Slide 31 text

Dynamic Secrets ● 通常の機密情報(Secrets Engines)はVault内に暗号化して保存 ● Dynamic Secretsは少し特殊 ○ アクセスのたびに自動で生成される

Slide 32

Slide 32 text

Dynamic Secrets アクセスのたびに自動でIAMユーザが作成される 設定したTTLが切れた際のIAMユーザ削除までVaultが責任を持って実施

Slide 33

Slide 33 text

認証にIAM、SecretsEngineにRDS

Slide 34

Slide 34 text

構成図

Slide 35

Slide 35 text

認証にIAM ● AWS SSOログイン後、接続したいDBが存在するアカウントに設定した IAMロールのCredentials を取得

Slide 36

Slide 36 text

認証にIAM ● Credentialsを使って署名した、署名済みリクエスト (sts:GetCallerIdentityRequest)を渡す

Slide 37

Slide 37 text

認証にIAM ● 署名済みリクエストをIAMのエンドポイントに送り、どのロールの Credentialsで署名したのか?を 確認

Slide 38

Slide 38 text

認証にIAM ● 認証完了!

Slide 39

Slide 39 text

SecretsEngineにRDS ● 正しいトークンが付与されたリクエストをなげる

Slide 40

Slide 40 text

SecretsEngineにRDS ● 認証済みユーザに対して何が認可できるか?をポリシーで確認 ○ 対象となるRDSインスタンス ○ 発行するDBユーザの権限

Slide 41

Slide 41 text

SecretsEngineにRDS ● DBユーザ/パスワードを作成する

Slide 42

Slide 42 text

SecretsEngineにRDS ● DBユーザ/パスワードをレスポンスとして返す

Slide 43

Slide 43 text

DBアクセスについて

Slide 44

Slide 44 text

Vaultは認証、認可のみ ● VaultによってDBの一時ユーザ/パスワードを入手 ● プライベートサブネットに配置したRDSに安全に接続する仕組みが必要 ● 開発者はSequelProなどのGUIツールが使いたい ○ SSMを使って踏み台インスタンスを用意するだけではだめ ○ SSHトンネリングが必要

Slide 45

Slide 45 text

SSM with SSH ● SSMを使ってSSH接続 ● SSH接続なのでSCPもSSHトンネリングもできる! ● ssm-userではなく、任意のユーザでSSH接続させられるのでルート権限も渡さずに済 む

Slide 46

Slide 46 text

まとめ

Slide 47

Slide 47 text

全体構成図

Slide 48

Slide 48 text

まとめと今後の展望 ● まとめ ○ VaultとIAMを組み合わせることでセキュアなDBアクセスの仕組みを実現 ● 今後の展望 ○ EC2によるDB踏み台がいらない構成にしてみたい! ■ Fargate踏み台やってみたいな〜

Slide 49

Slide 49 text

最後に宣伝!

Slide 50

Slide 50 text

積極採用中です! ● 採用ページ ○ https://recruit.hamee.co.jp/odawara ● 珍しい福利厚生 ○ 小田原手当 ■ 小田原周辺地域に居住する正社員に対し、月2万円を支給! ○ いざ!小田原 ■ 正社員の新幹線・特急電車・飛行機・船・高速バスでの通勤OK

Slide 51

Slide 51 text

ご静聴ありがとうございました!

Slide 52

Slide 52 text

No content