JAWSDAYS2021
HashiCorp Vaultを使ったセキュアなDBアクセスの実現横山達男(@tatsuo4848) | 2021/03/20
View Slide
本セッションのターゲット● RDSのパスワード管理に悩んでいる方● HashiCorp Vaultでどんなことができるのか興味がある方
小田原にあるHameeから来ました！
自己紹介twitterアカウント：@tatsuo4848GitHubアカウント：tatsuo48~ これまでの経歴 ~拝承系SIer(インフラエンジニア、お客様サポート)⬇株式会社みんなのウェディング(インフラエンジニア、SRE)⬇Hamee株式会社(SRE、TechLead)三度の飯よりAWSが好き
Hameeについて
Next Engineの機能
Next Engineのシステム構成メイン機能PlatformAPIアプリアプリアプリアプリ アプリアプリ
Next Engineのシステム構成メイン機能PlatformAPIアプリアプリアプリアプリ アプリアプリAWSで運用中
Next Engineのシステム構成メイン機能PlatformAPIアプリアプリアプリアプリ アプリアプリAWSで運用予定(さくらインターネットから移行中 )AWSで運用中
Next Engineのシステム構成(移行完了後)メイン機能PlatformAPIアプリアプリアプリアプリ アプリアプリAuroraクラスター
メイン機能Next Engineのシステム構成(移行完了後)PlatformAPIアプリアプリアプリアプリ アプリアプリAuroraクラスター AuroraクラスターAuroraクラスター Auroraクラスター
メイン機能Next Engineのシステム構成(移行完了後)PlatformAPIアプリアプリアプリアプリ アプリアプリAuroraクラスター AuroraクラスターAuroraクラスター AuroraクラスターAuroraクラスターAuroraクラスターAuroraクラスターAuroraクラスターAuroraクラスター
増え続けるDBインスタンスのユーザ管理をどうする？
課題● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする？○ 問い合わせ対応などで開発者ごとのDBユーザ発行は必須！
課題● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする？○ 共通ユーザを作成■ 定期的なパスワードローテーションが必要■ パスワードの安全な共有方法が必要
課題● サービス成長と共に増えつづけるDBインスタンスのユーザ管理をどうする？○ 共通ユーザを作成■ 定期的なパスワードローテーションが必要■ パスワードの安全な共有方法が必要○ 開発者ごとにDBユーザを作成■ 定期的なパスワードローテーションが必要■ 入社、退社時の作業コストが大
どちらの手段も一長一短
HashiCorp Vaultで解決！
HashiCorp Vaultで解決！● IAM認証情報を元にRDSの期限付きユーザを発行する仕組みを構築○ パスワードローテーション不要○ パスワード共有方法も考えなくていい○ 入社退社時にIAMの更新対応は元から必要なので新規コストは発生せず
全体構成図
HashiCorp Vaultについて
HashiCorp Vaultについて● Terraformで有名なHashiCorp社が開発したプロダクト● 機密情報管理● 以下を行ってくれる○ 任意の認証基盤(Auth Methods)を使った認証○ ポリシー(Policies)に基づき機密情報(Secrets Engines)へのアクセスを認可● Dynamic Secretsという動的な機密情報生成の仕組み
認証と認可● めちゃくちゃわかりやすい記事がありますのでそちらをお読みください○ 出典：DevelopersIO，よくわかる認証と認可○ https://dev.classmethod.jp/articles/authentication-and-authorization/
認証と認可● めちゃくちゃわかりやすい記事がありますのでそちらをお読みください○ 出典：DevelopersIO，よくわかる認証と認可○ https://dev.classmethod.jp/articles/authentication-and-authorization/● 認証は「通信の相手が誰（何）であるかを確認すること」● 認可は「とある特定の条件に対して、リソースアクセスの権限を与えること」
認証と認可(HashiCorp Vaultの場合)
認証と認可(HashiCorp Vaultの場合)認証は「認証情報を元に、認証基盤に正しい通信相手か確認すること」
認証と認可(HashiCorp Vaultの場合)認証は「認証情報を元に、認証基盤に正しい通信相手か確認すること」認可は「認証が通ったユーザに、ポリシーに基づいて機密情報へのアクセス権限を与えること」
Dynamic Secrets● 通常の機密情報(Secrets Engines)はVault内に暗号化して保存● Dynamic Secretsは少し特殊○ アクセスのたびに自動で生成される
Dynamic Secretsアクセスのたびに自動でIAMユーザが作成される設定したTTLが切れた際のIAMユーザ削除までVaultが責任を持って実施
認証にIAM、SecretsEngineにRDS
構成図
認証にIAM● AWS SSOログイン後、接続したいDBが存在するアカウントに設定したIAMロールのCredentialsを取得
認証にIAM● Credentialsを使って署名した、署名済みリクエスト(sts:GetCallerIdentityRequest)を渡す
認証にIAM● 署名済みリクエストをIAMのエンドポイントに送り、どのロールのCredentialsで署名したのか？を確認
認証にIAM● 認証完了！
SecretsEngineにRDS● 正しいトークンが付与されたリクエストをなげる
SecretsEngineにRDS● 認証済みユーザに対して何が認可できるか？をポリシーで確認○ 対象となるRDSインスタンス○ 発行するDBユーザの権限
SecretsEngineにRDS● DBユーザ/パスワードを作成する
SecretsEngineにRDS● DBユーザ/パスワードをレスポンスとして返す
DBアクセスについて
Vaultは認証、認可のみ● VaultによってDBの一時ユーザ/パスワードを入手● プライベートサブネットに配置したRDSに安全に接続する仕組みが必要● 開発者はSequelProなどのGUIツールが使いたい○ SSMを使って踏み台インスタンスを用意するだけではだめ○ SSHトンネリングが必要
SSM with SSH● SSMを使ってSSH接続● SSH接続なのでSCPもSSHトンネリングもできる！● ssm-userではなく、任意のユーザでSSH接続させられるのでルート権限も渡さずに済む
まとめ
まとめと今後の展望● まとめ○ VaultとIAMを組み合わせることでセキュアなDBアクセスの仕組みを実現● 今後の展望○ EC2によるDB踏み台がいらない構成にしてみたい！■ Fargate踏み台やってみたいな〜
最後に宣伝！
積極採用中です！● 採用ページ○ https://recruit.hamee.co.jp/odawara● 珍しい福利厚生○ 小田原手当■ 小田原周辺地域に居住する正社員に対し、月2万円を支給！○ いざ！小田原■ 正社員の新幹線・特急電車・飛行機・船・高速バスでの通勤OK
ご静聴ありがとうございました！
tatsuo48
.png){kind=icon}
pharma_x_tech
hayaosuzuki
daihiraoka
taishin
shimap_sampo
weblyzard
asei
kawaguti
hato3isfriend
yu4u
keithyokoma
lamrongol
thekraken
nonsquared
soudai
mraible
bermonpainter
rasmusluckow
maggiecrowley
destraynor
geeforr
hannesfritz
sugarenia
sonatard