Slide 1

Slide 1 text

AWS Systems Manager Change Managerを 利用した本番アクセス統制 大島 悠司 JAWS-UG情シス支部 第28回

Slide 2

Slide 2 text

自己紹介 ◼ 大島 悠司(おおしま ゆうじ) • ニューリジェンセキュリティ株式会社 • クラウドセキュリティアーキテクト/基盤リーダー • 2022 APN ALL AWS Certifications Engineers ◼ 経歴 • デジタルフォレンジック、マルウェア解析、スレットインテリジェンス • SOC、基盤運用、インシデントレスポンス • ニューリジェンの創業メンバーとして サービス開発/基盤構築運用/研究開発に従事 Azure×6, GCP×4 CISSP, GIAC×3, ISACA×2 yuj1osm 2

Slide 3

Slide 3 text

アジェンダ ◼ マルチアカウント構成とIAM設計 ◼ Change Managerで実現する本番アクセス統制 3

Slide 4

Slide 4 text

マルチアカウント構成とIAM設計 4

Slide 5

Slide 5 text

マルチアカウント ◼ マルチアカウント構成のメリット • セキュリティやガバナンスの向上 • 課金の分離 • 運用の効率化 ◼ アカウント分離の切り口 • 開発環境 • ステージング環境 • 本番環境 AWS Cloud(開発) AWS Cloud(ステージング) AWS Cloud(本番) 5

Slide 6

Slide 6 text

各アカウントにIAMユーザを作成 ◼ IAMユーザを各アカウントに作るデメリット • アカウントごとにログインが必要になる • IAMユーザが増えるにつれてポリシーの管理が複雑化 • セキュリティリスクが高まる AWS Cloud(開発) User1 User2 User3 AWS Cloud(ステージング) User1 User2 User3 AWS Cloud(本番) User1 User2 User3 User1 User2 User3 各AWSアカウントへ それぞれログイン 6

Slide 7

Slide 7 text

Jumpアカウント方式 ◼ Jumpアカウントを用意し、IAMユーザを集約 ◼ 利用者はJumpアカウントにログインし、各アカウントへスイッチロール ◼ 各アカウントの権限はスイッチ先ロールに付与 AWS Cloud(開発) AWS Cloud(ステージング) AWS Cloud(本番) User1 User2 User3 Jumpアカウントへ ログイン AWS Cloud(Jump) User1 User2 User3 Role Permissions Role Permissions Role Permissions AWS STS 各アカウントへ スイッチロール Permissions 7

Slide 8

Slide 8 text

IAM設計のコツ ◼ 役割ごとにグループを分ける ◼ グループに対して、スイッチできるアカウントとロールを固定 • リーダーグループは高権限のロール、メンバーグループは低権限のロールにスイッチ • 読み取り専用権限のロールもあると安心 8

Slide 9

Slide 9 text

本番環境へのアクセス統制どうする? ◼ 変更管理 • 誰が、いつ、変更作業のために本番環境にログインしたか追える? ◼ 本番アクセス統制 • 本番環境にいつでもログインできるようになっていないか? ここをどうやって 管理・統制する? 9

Slide 10

Slide 10 text

Change Managerで実現する本番アクセス統制 10

Slide 11

Slide 11 text

Change Managerでアクセス管理 ◼ Change Managerとは? • AWS Systems Managerの1機能であり、アプリやインフラの変更管理を提供 • 承認フローを組める ◼ どのように変更管理と本番アクセス統制をするか • 本番アクセス用グループを新たに作成 • このグループからのみ本番環境の作業ロールにスイッチ可能 • Change Managerの承認でこのグループに追加 • グループ追加とともにTTLタグをつける ※グループの参加期限を示したタグ 11

Slide 12

Slide 12 text

結論から ◼ これを作ります 12

Slide 13

Slide 13 text

Change Managerセットアップ ◼ 機能を委任する 13

Slide 14

Slide 14 text

Quick Setup ◼ 機能をメンバーアカウントに委任する Systems ManagerのQuick Setupから、 Change Managerをセットアップ 委任管理者アカウント、権限、変更が及ぶ 範囲(組織やOU単位)で設定 14

Slide 15

Slide 15 text

テンプレート作成 ◼ ドキュメントとテンプレート 15

Slide 16

Slide 16 text

ドキュメントを作成する ◼ Change Managerテンプレートはドキュメントを参照するので、まずはドキュメントを作成 ・ドキュメントは具体的なタスクを定義 ・AWS APIを叩ける ・yamlで記載できる ・ここで2つのドキュメントを作成する ①グループ追加 & TTLタグ付与 ②グループ離脱 & TTLタグ削除 ※TTLタグ:どのグループに、いつまで 追加され続けるか管理 16

Slide 17

Slide 17 text

テンプレートを作成する ◼ 参照するドキュメントを指定し、Change Managerテンプレートを作成 ・テンプレートは承認者や通知先を定義 ・yamlで記載できる ・ここで2つのテンプレートを作成する ①グループ追加 & TTLタグ付与 ②グループ離脱 & TTLタグ削除 17

Slide 18

Slide 18 text

テンプレートを承認 ◼ テンプレート登録には承認が必要 テンプレート作成者がレビュー依頼 承認者がコメント付きで承認 承認済みになり使えるようになる 18

Slide 19

Slide 19 text

動作確認 ◼ 承認フローを得て本番環境にアクセスできるか確認 19

Slide 20

Slide 20 text

事前アクセス確認 ◼ ProdMemberWorkGroupに所属していないのでスイッチ不可 20

Slide 21

Slide 21 text

リクエスト作成 ◼ 本番作業をするユーザがリクエストを作成する リクエストを作成する パラメータを入力 ・IAMユーザ名 ・グループ名(本番作業グループ) ・TTL(作業終了日時) 承認依頼 21

Slide 22

Slide 22 text

リクエスト承認 ◼ 承認者が承認する タスクが実行される 承認者がコメント付きで承認 タイムラインでタスクのステータスや 承認者が見れる 22

Slide 23

Slide 23 text

本番環境へスイッチロール ◼ 再度、本番環境へスイッチロールしてみる リクエスト作成で入力した グループへの追加と、 TTLタグが付いている 今度は本番環境へスイッチロールできた 23

Slide 24

Slide 24 text

作業終了のリクエスト忘れへの対策 ◼ 作業終了のリクエストがされなければ本番アクセスできたままになってしまう ◼ ここでTTLタグを使って強制的にグループ離脱をさせる 例えば、以下のようなLambdaで定期的に実行 ・全ユーザのタグ値と現在日時を比較する ・タグ値 < 現在日時 なら、タグとともにタグキーに 記載のグループから離脱させる ・強制離脱させた場合やタグ値のフォーマット誤りが あれば、エラーメールを出す メール例 24

Slide 25

Slide 25 text

全体図を振り返り 25

Slide 26

Slide 26 text

まとめ ◼ マルチアカウント構成やIAM設計は、本番環境へのアクセス権限が過剰でないかを確認 ◼ サイバー攻撃だけでなく、内部不正対策として変更管理やアクセス統制も重要 ◼ Change Managerを使うことで変更管理とアクセス統制の仕組みを実装可能 26