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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全体図を振り返り 25

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