Slide 1

Slide 1 text

SREチームによる AWSアカウント運用効率化 メドピア株式会社 侘美 怜

Slide 2

Slide 2 text

自己紹介 名前 侘美 怜(たくみ さとし) アカウント @reirei_As reireias 略歴 2013年 富士ゼロックスに入社 BtoBのSaaSプロダクトの開発 オンプレからAWSへの移行 2019年 メドピアに入社 SREチーム所属 たまにRailsエンジニア

Slide 3

Slide 3 text

メドピアのサービス・事業

Slide 4

Slide 4 text

SREチーム:組織 各サービスの開発チームはエンジニア3〜5名で構成され、15チームほど SREチームは全サービスを横断的に見る立ち位置

Slide 5

Slide 5 text

SREチーム:役割・業務 SREの主な役割 ● インフラ構築・改修・パフォーマンスチューニング ● モニタリングの設定・運用 ● AWS上のセキュリティの担保 ● GitHubやRollbarなど、全社的に開発で利用するツールの管理 各サービスごとに主担当のSREが一人 = SRE一人あたり数サービスを担当

Slide 6

Slide 6 text

SREチーム:データ サービス数・SREチーム共にまだまだ成長中! 2021 2020 2019 2018 2017 2016 2015 AWSアカウント 48個 SRE 6名 PullRequest 85/週

Slide 7

Slide 7 text

こんなSREチームのAWSアカウント運用上の工夫をご紹介 効
 率
 化


Slide 8

Slide 8 text

アジェンダ ● Terraform ● セキュリティ ● IAMユーザー

Slide 9

Slide 9 text

Terraform

Slide 10

Slide 10 text

Terraform CloudによるCI/CDパイプライン Terraform Cloud HashiCorp社のTerraformマネージドサービス https://www.terraform.io/cloud 機能 ● Terraformのstateの管理機能 ● Terraformのplan(変更の差分の表示)やapply(変更の反映)の実行環境 ● Terraformモジュールのレジストリ ○ IAMロール、通知系のLambda関数、会社のIPなどの定数、等をモジュールとして登録し活用中

Slide 11

Slide 11 text

Terraform CloudによるCI/CDパイプライン Terraform Cloud GitHub Pull Request作成 merge plan実行 apply実行 各種リソース Trigger Trigger Apply Read こんなCI/CDパイプラインが実現可能 ※ Terraform Cloud以外のツールでも同様のパイプラインは構築可能

Slide 12

Slide 12 text

Terraform CloudによるCI/CDパイプライン メリット①:Terraform実行用のクレデンシャル管理の改善 Before ● AWSアカウント単位でクレデンシャルを発行 ● SREのマシンのローカルに保存 After ● Terraform Cloudにクレデンシャルを登録 ● SREはTerraform Cloudへログインするだけ 工数削減 + セキュリティ向上

Slide 13

Slide 13 text

補足:Terraform Cloudに渡すクレデンシャル 普通に移行するとAWSアカウントの数だけIAMユーザーのクレデンシャルを登録する必 要がでてきてしまう。 OrganizationAccountAccessRoleという、管理アカウントのIAMユーザーから利用でき るロールを使うことで、Terraform Cloudには管理アカウント上のIAMユーザーのクレデ ンシャルを1個のみ登録するだけでよくなる。 後は各Terraform側で任意のアカウントにAssumeRoleする実装とすれば良い。

Slide 14

Slide 14 text

Terraform CloudによるCI/CDパイプライン メリット②:構成の統一 Before ● MakefileやDockerを使ってTerraformを実行する実装が一部残っていた ● 新規参入者の障壁 = 古いリポジトリがより放置される ● SRE外からもPRを投げづらい After ● PR作成→plan実行/PRマージ→applyに統一 ● SRE外からも気軽にPRを投げられるように

Slide 15

Slide 15 text

Terraform CloudによるCI/CDパイプライン メリット③:apply忘れやエラー放置の撲滅 Before ● PRマージしたけどapply忘れてました ● applyエラーになったけど後で直します →放置 After ● 自動apply(※)による担保 ● 一覧で表示されるのでエラーに気付ける ※ ちなみに、確認画面をはさんで apply という設定も可能

Slide 16

Slide 16 text

SRE相互でのコードレビュー SREチームのレビュールール ● 他のSRE1名以上のapproveが必要 ● 基本はSREチームメンバーでランダムアサイン メリット ● 最新のAWSの機能や良い実装のサービス間での横展開 ● IaCのコード再利用性の高さがより発揮される デメリット ● AWSの知見がSREチームのみに蓄積される

Slide 17

Slide 17 text

セキュリティ

Slide 18

Slide 18 text

効率的なセキュリティの担保 セキュリティルール準拠状態をチェックし可視化 少ない工数でいかにセキュリティを担保するかを追求した構成 特徴 ● 全アカウントに対して、設定したセキュリティルールに準拠しているかを自動で チェック ● 新規アカウントに対しても自動的にチェック対象とする ● アカウント毎のセキュリティルールへの準拠状態をダッシュボード表示

Slide 19

Slide 19 text

Log Account Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config ・ ・ ・ 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート

Slide 20

Slide 20 text

Service Account 1 Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート ・ ・ ・ CloudFormation StackSetsにより Organizations配下の全アカウントへの AWS Configの設定 AWS ConfigのOrganization Config Rule機能で全アカウントにルールを設定

Slide 21

Slide 21 text

Log Account Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート ・ ・ ・ Configのスナップショットログ を1つのS3バケットに集約

Slide 22

Slide 22 text

Log Account Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート Athena + QuickSightで集計 と分析 ・ ・ ・

Slide 23

Slide 23 text

Log Account Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config ・・ ・ 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート ダッシュボードや月イチのレポートメールでセ キュリティ対策状況をチェック ダッシュボードのサンプル

Slide 24

Slide 24 text

Log Account Root Account セキュリティの可視化 CloudFormation Config Organizations Service Account 1 Config Service Account N Config ・・ ・ 作成 & ルール設定 Bucket ログ保存 Athena QuickSight SRE レポート より詳細が気になる方はこちらのテックブログへ AWS Config + Athena + QuickSightによる複数AWSアカウント横 断でのセキュリティ状態の可視化 - メドピア開発者ブログ https://tech.medpeer.co.jp/entry/2021/10/01/090000

Slide 25

Slide 25 text

tfsecの導入とDependabotの活用 セキュリティ対策の工数削減として役立ったTips ● tfsec ○ https://github.com/aquasecurity/tfsec ○ Terraformのコードを解析して潜在的なセキュリティ問題を警告してくれるツール ○ AWSには一度作成すると修正が難しいリソースもあるので有用 ● DependabotによるAWS Providerの更新PR作成 ○ GitHubに組み込まれているツールで、リポジトリ内のライブラリのセキュリティアラートや更新の PR などを発行してくれる ○ Terraformのプロバイダーやモジュールにも対応しているので、 AWS Providerを最新に保つのが楽

Slide 26

Slide 26 text

セキュリティ可視化 + tfsecによる効果 Before ● 実装時期や実装者によってセキュリティ対策はまばら ● セキュリティに関する社内ルールはあるが、どのアカウントでどれくらい守られてい るかチェックが難しい After ● 静的解析と実際のリソースをチェックすることでセキュリティを担保 ● 可視化 することで、定量的にセキュリティ対策状況を把握できる ● 改善すべき対象が浮き彫りに

Slide 27

Slide 27 text

IAMユーザー

Slide 28

Slide 28 text

Service Account A IAMユーザーの運用方法 intra Account 開発者 IAMユーザー IAMロール 各種リソース 操作 Service Account B IAMロール 各種リソース 操作 Assume Role ● 開発者用のIAMユーザーは1アカウントに 集約 ● どのIAMロールにAssume Role可能かも ここで制御 ・ ・

Slide 29

Slide 29 text

Service Account A IAMユーザーの運用方法 intra Account 開発者 IAMユーザー IAMロール 各種リソース 操作 Service Account B IAMロール 各種リソース 操作 Assume Role ● 各AWSアカウントを操作する際は Assume Roleして操作 ・ ・

Slide 30

Slide 30 text

Service Account A IAMユーザーの運用方法 intra Account 開発者 IAMユーザー IAMロール 各種リソース 操作 Service Account B IAMロール 各種リソース 操作 Assume Role ● 各AWSアカウント上のIAMロールは Terraformのモジュールでadminや readonlyなどいくつかのパターンを用意 ・ ・

Slide 31

Slide 31 text

IAMユーザーの運用方法 この方式のメリット ● IAMユーザーの数を減らし、アクセスキーの流出リスクを低減 ● アクセスキーの定期ローテーションを現実的な工数で実現可能(後述) ● 権限を一元管理できる

Slide 32

Slide 32 text

アクセスキーのローテーション運用の課題 ● IAMユーザーのアクセスキーは定期的な変更がベストプラクティスである ○ ローテーションできるように、 IAMユーザー毎に2個まで作成できるようになっている ● 開発者に「自身で更新してください」では更新しない開発者が出てくる ● SRE側で強制的に新しいアクセスキーに更新したいが、SREが開発者のキーを見 てしまうとセキュリティ上問題がある ○ SREが任意の開発者になりすまして AWSを操作可能になってしまう 開発者のアクセスキーを閲覧せずに、強制的に更新という方式で実現したい!

Slide 33

Slide 33 text

アクセスキーの発行のための仕組み 開発者 SRE Terraform 提出 実装 IAMアクセスキー 発行 apply 暗号化 利用 output ㊙ 復号 公開鍵 秘密鍵 IAMアクセスキー 暗号化された アクセスキー ① 開発者がPGP鍵を生成し、公開鍵を SREに提出。

Slide 34

Slide 34 text

アクセスキーの発行のための仕組み 開発者 SRE Terraform 提出 実装 IAMアクセスキー 発行 apply 暗号化 利用 output ㊙ 復号 公開鍵 秘密鍵 IAMアクセスキー 暗号化された アクセスキー ② PGP鍵を指定しIAMアクセスキー作成を実装。

Slide 35

Slide 35 text

アクセスキーの発行のための仕組み 開発者 SRE Terraform 提出 実装 IAMアクセスキー 発行 apply 暗号化 利用 output ㊙ 復号 公開鍵 秘密鍵 IAMアクセスキー 暗号化された アクセスキー ③ applyすると、作成されたIAMアクセスキーがPGP公開鍵で暗号化される。

Slide 36

Slide 36 text

アクセスキーの発行のための仕組み 開発者 SRE Terraform 提出 実装 IAMアクセスキー 発行 apply 暗号化 利用 output ㊙ 復号 公開鍵 秘密鍵 IAMアクセスキー 暗号化された アクセスキー ④ SREは暗号化されたIAMアクセスキーを開発者に伝達し、開発者は復号する。

Slide 37

Slide 37 text

アクセスキーの発行のための仕組み 開発者 SRE Terraform 提出 実装 IAMアクセスキー 発行 apply 暗号化 利用 output ㊙ 復号 公開鍵 秘密鍵 IAMアクセスキー 暗号化された アクセスキー SREが生のIAMアクセスキーを目撃することなく、 強制的にIAMアクセスキーを発行できた! ↓ ローテーションに必要な工数を大幅削減

Slide 38

Slide 38 text

まとめ Terraform、セキュリティ、IAMユーザー関連の効率化のためにメドピアが行っている工 夫をいくつか紹介した 特に以下2点はかなりの効率化が見込めるので是非導入をおすすめしたい ● IaCのCI/CDパイプライン ● Organizations関連機能の活用