1時間は短すぎる？許可セットのセッション時間で開発チームと見つけた着地点

Transcript

1. 1時間は短すぎる？ 許可セットのセッション時間で 開発チームと見つけた着地点 JAWS-UG 彩の国埼玉支部 北川 卓図 ＠zukutakuzu
2. 自己紹介 北川 卓図 CCoE 某事業会社で働くCCoE 担当業務：FinOps/DevSecOps推進 日々RI/SP購入に追われています 共用RI/SPの早期導入を願っています 好きなAWSサービス：StepFunction ＠zukutakuzu
3. 本セッションで話すこと/話さないこと 本セッションで話すこと どのようにセッション時間を決めたかのストーリー 開発チームと運用ルールを決めたプロセス 事業会社ならではのコミュニケーション 本セッションで話さないこと Identity Centerの基本的な設定方法や構築手順 セッション時間の技術的な仕様 テクニカル寄りの話
4. セキュリティ vs 運用効率性 セキュリティ 運用効率性
5. 皆さん 許可セットのセッション時間 何時間に設定していますか？
6. 許可セットのセッション時間とは IAM Identity Center > 許可セット > セッション時間
7. 許可セットのセッション時間とは セッション時間が切れるとこんな画面が出ます
8. どうセッション時間を決めていったか ①導入 ②衝突 ③最適化
9. ステークホルダー説明 AWS Organizations 超重要システム 社内利用システム CCoE 開発チームA 開発チームB エンドユーザー 社内ユーザー 開発・運用 運用・保守 Orgnizations管理 CSPM・FinOps
10. ①導入
11. https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/howtosessionduration.html 公式ドキュメントでは、、
12. 「ロールを実行するために 必要な長さ」って 具体的に何時間だ？ 初めの所感 世の中の事例には個人利用で 4時間とか書いてあるけど ・・・・・・
13. AWSで実際にログインしてやる作業の例 EC2設定変更 リソース起動停止 CloudWatchメトリクス確認 ダッシュボード確認 スナップショット取得 IAMポリシー変更 Route53 レコード追加 短時間作業 中時間作業 長時間作業 単一ログ調査 IaaS構築(VPC ～ミドル構築) CFn Stackデプロイ SystemManagerでパッチ適用 ELBターゲットグループ設定 RDSリードレプリカ作成 複数サービス結合テスト 複数にまたがるログ調査 GuardDutyアラート詳細調査 大容量ログダウンロード Athenaで大規模クエリ実行 監査証跡収集 EC2障害調査 DDoS攻撃時WAFログ調査
14. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ とりあえずデフォルトでやってみることに 短時間作業 長時間作業 やる作業ベースで網羅的にセッション時間を設計するのは困難 許可セット作成時のデフォルト時間は1時間 1時間でセッション切れるなら本番環境でもそこまでセキュリテ ィリスクはないだろうという感覚 導入にあたってスケジュールも迫られているのもあって、すべて の許可セットセッション時間をデフォルトの1時間とした
15. ②衝突
16. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ とある日、、 短時間作業 長時間作業 障害発生したんですが 1時間でセッションが切れると困る！！ 何とかしてほしい！！！
17. 短時間作業 長時間作業 具体的には障害時のどんな作業でセッション切れになりますか？ 土日含む緊急対応の際にセッションが切れてしまいます 具体的にはCloudWatch Logs のクエリ実行、内容確認 Session Manager接続してEC2のログ確認　など 攻撃を受けた際は一刻も早く解明が必要です 緊急対応なのでPower権限(AdministratorAccess - IAM系権限)で 実行する必要があります ReadOnlyポリシー相当のセッション時間を 延ばすことで解決になりますか ヒアリングやり取り CCoE CCoE 開発チームA 開発チームA
18. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 短時間作業 長時間作業 緊急対応のために全環境一律 セッション時間を延ばすと 単純にセキュリティリスクが増える 顧客に大影響を与えるシステムの本番環境のみ 「緊急用 許可セット」 を用意し セッション時間を1時間→4時間に拡張した 緊急用 許可セットはPower権限を付与した 「緊急用 許可セット」が使用されたことに 気付ける仕組みを作った 解決策
19. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 構成図 Identity Center経由ログインのCloudTrailイベント調査と通知実装 #AWS - Qiita
20. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 環境 ロール セッション時間 本番環境/ 検証環境/ 開発環境 通常用 1時間 緊急用 4時間 セッション時間設計はこうなりました 短時間作業 長時間作業 通常用(1時間) と 緊急用(4時間) の両方を用意
21. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ また、とある日、、 短時間作業 長時間作業 セッション切れが頻発に発生します セキュリティ上緩められないのは理解できるのですが 落としどころは無いですか？
22. 短時間作業 長時間作業 どのような作業でセッション切れになるか具体的例はありますか 基本開発作業や運用作業です ユーザーから問い合わせが来た際にAWS上で調査しますが 内容が複雑だったりすると1時間を超えてしまいます 利用頻度が高いのはどの環境でしょう 開発環境や検証環境のみセッション時間を延ばすのは 解決策になりますか？ 一番困っているのは開発環境/検証環境です セッションが長くなれば開発やテストで効率が良くなります ヒアリングやり取り 開発チームB 開発チームB CCoE CCoE
23. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 短時間作業 長時間作業 本番環境のセッション時間を延ばすのは セキュリティリスクが高まる ヒアリングを重ねることで対象環境を開発環境と検証環境に 絞ることができた 開発環境と検証環境のセッション時間を 一律 1時間 → 2時間に設定した 解決策
24. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ セッション時間設計はこうなりました 短時間作業 長時間作業 本番環境以外はセッション時間を2時間に 環境 ロール セッション時間 本番環境 通常用 1時間 緊急用 4時間 検証環境 通常用 2時間 開発環境 通常用 2時間
25. ③最適化
26. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 2つの解決策を取り入れた結果 短時間作業 長時間作業 Before After 環境 ロール セッション 時間 本番環境 通常用 1時間 緊急用 4時間 検証環境 通常用 2時間 開発環境 通常用 2時間 環境 セッション時間 全環境 1時間 本当に守るべき環境と用途のセッション時間は変えずに 要件を細分化し、運用効率性を考慮し、柔軟に設計した
27. VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 2チームとヒアリングを行った所感 短時間作業 長時間作業 slackで依頼されたらそのまま文面を受け取るだけではなくて 「具体的には？」「どんなケース？」と深堀するのが大事 深堀することで相手も納得しセキュリティ統制上も問題ないと判 断できる着地点が見つかりやすい 結局のところ人対人のコミュニケーションに行きつくので、相手 のペインを解消することを大事にすると、感情的にもこちら側の 要望も受け入れてもらいやすい
28. セキュリティ vs 運用効率性 セキュリティ 運用効率性 セキュリティと運用効率性はトレ ードオフの関係 セキュリティは企業が所有するシ ステムを管理する以上、絶対考慮 しないといけない ただ、運用効率性を度外視すると 開発チームからのヘイトが高ま り、最悪コミュニケーション不足 の関係になることも
29. これって正解はないですよね、、
30. 状況は現場に応じて異なります。 運用効率性も考えて現場の声を聴いて 一般的なセキュリティ指標の価値観や感覚は コミュニティなどで情報吸収 することが大事と考えます。
31. まとめ セキュリティ 運用効率性 バランスをとって、両方実現していきましょう！
32. ご清聴ありがとう ございました！ JAWS-UG 彩の国埼玉支部 北川 卓図 ＠zukutakuzu