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

by zukutakuzu

Slide 1

Slide 1 text

1時間は短すぎる？許可セットのセッション時間で開発チームと見つけた着地点 JAWS-UG 彩の国埼玉支部北川卓図＠zukutakuzu

Slide 2

Slide 2 text

自己紹介北川卓図 CCoE 某事業会社で働くCCoE 担当業務：FinOps/DevSecOps推進日々RI/SP購入に追われています共用RI/SPの早期導入を願っています好きなAWSサービス：StepFunction ＠zukutakuzu

Slide 3

Slide 3 text

本セッションで話すこと/話さないこと本セッションで話すことどのようにセッション時間を決めたかのストーリー開発チームと運用ルールを決めたプロセス事業会社ならではのコミュニケーション本セッションで話さないこと Identity Centerの基本的な設定方法や構築手順セッション時間の技術的な仕様テクニカル寄りの話

Slide 4

Slide 4 text

セキュリティ vs 運用効率性セキュリティ運用効率性

Slide 5

Slide 5 text

皆さん許可セットのセッション時間何時間に設定していますか？

Slide 6

Slide 6 text

許可セットのセッション時間とは IAM Identity Center > 許可セット > セッション時間

Slide 7

Slide 7 text

許可セットのセッション時間とはセッション時間が切れるとこんな画面が出ます

Slide 8

Slide 8 text

どうセッション時間を決めていったか ①導入 ②衝突 ③最適化

Slide 9

Slide 9 text

ステークホルダー説明 AWS Organizations 超重要システム社内利用システム CCoE 開発チームA 開発チームB エンドユーザー社内ユーザー開発・運用運用・保守 Orgnizations管理 CSPM・FinOps

Slide 10

Slide 10 text

①導入

Slide 11

Slide 11 text

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/howtosessionduration.html 公式ドキュメントでは、、

Slide 12

Slide 12 text

「ロールを実行するために必要な長さ」って具体的に何時間だ？初めの所感世の中の事例には個人利用で 4時間とか書いてあるけど・・・・・・

Slide 13

Slide 13 text

AWSで実際にログインしてやる作業の例 EC2設定変更リソース起動停止 CloudWatchメトリクス確認ダッシュボード確認スナップショット取得 IAMポリシー変更 Route53 レコード追加短時間作業中時間作業長時間作業単一ログ調査 IaaS構築(VPC ～ミドル構築) CFn Stackデプロイ SystemManagerでパッチ適用 ELBターゲットグループ設定 RDSリードレプリカ作成複数サービス結合テスト複数にまたがるログ調査 GuardDutyアラート詳細調査大容量ログダウンロード Athenaで大規模クエリ実行監査証跡収集 EC2障害調査 DDoS攻撃時WAFログ調査

Slide 14

Slide 14 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウとりあえずデフォルトでやってみることに短時間作業長時間作業やる作業ベースで網羅的にセッション時間を設計するのは困難許可セット作成時のデフォルト時間は1時間 1時間でセッション切れるなら本番環境でもそこまでセキュリティリスクはないだろうという感覚導入にあたってスケジュールも迫られているのもあって、すべての許可セットセッション時間をデフォルトの1時間とした

Slide 15

Slide 15 text

②衝突

Slide 16

Slide 16 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウとある日、、短時間作業長時間作業障害発生したんですが 1時間でセッションが切れると困る！！何とかしてほしい！！！

Slide 17

Slide 17 text

短時間作業長時間作業具体的には障害時のどんな作業でセッション切れになりますか？土日含む緊急対応の際にセッションが切れてしまいます具体的にはCloudWatch Logs のクエリ実行、内容確認 Session Manager接続してEC2のログ確認　など攻撃を受けた際は一刻も早く解明が必要です緊急対応なのでPower権限(AdministratorAccess - IAM系権限)で実行する必要があります ReadOnlyポリシー相当のセッション時間を延ばすことで解決になりますかヒアリングやり取り CCoE CCoE 開発チームA 開発チームA

Slide 18

Slide 18 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ短時間作業長時間作業緊急対応のために全環境一律セッション時間を延ばすと単純にセキュリティリスクが増える顧客に大影響を与えるシステムの本番環境のみ「緊急用許可セット」を用意しセッション時間を1時間→4時間に拡張した緊急用許可セットはPower権限を付与した「緊急用許可セット」が使用されたことに気付ける仕組みを作った解決策

Slide 19

Slide 19 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ構成図 Identity Center経由ログインのCloudTrailイベント調査と通知実装 #AWS - Qiita

Slide 20

Slide 20 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ環境ロールセッション時間本番環境/ 検証環境/ 開発環境通常用 1時間緊急用 4時間セッション時間設計はこうなりました短時間作業長時間作業通常用(1時間) と緊急用(4時間) の両方を用意

Slide 21

Slide 21 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウまた、とある日、、短時間作業長時間作業セッション切れが頻発に発生しますセキュリティ上緩められないのは理解できるのですが落としどころは無いですか？

Slide 22

Slide 22 text

短時間作業長時間作業どのような作業でセッション切れになるか具体的例はありますか基本開発作業や運用作業ですユーザーから問い合わせが来た際にAWS上で調査しますが内容が複雑だったりすると1時間を超えてしまいます利用頻度が高いのはどの環境でしょう開発環境や検証環境のみセッション時間を延ばすのは解決策になりますか？一番困っているのは開発環境/検証環境ですセッションが長くなれば開発やテストで効率が良くなりますヒアリングやり取り開発チームB 開発チームB CCoE CCoE

Slide 23

Slide 23 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ短時間作業長時間作業本番環境のセッション時間を延ばすのはセキュリティリスクが高まるヒアリングを重ねることで対象環境を開発環境と検証環境に絞ることができた開発環境と検証環境のセッション時間を一律 1時間 → 2時間に設定した解決策

Slide 24

Slide 24 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウセッション時間設計はこうなりました短時間作業長時間作業本番環境以外はセッション時間を2時間に環境ロールセッション時間本番環境通常用 1時間緊急用 4時間検証環境通常用 2時間開発環境通常用 2時間

Slide 25

Slide 25 text

③最適化

Slide 26

Slide 26 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 2つの解決策を取り入れた結果短時間作業長時間作業 Before After 環境ロールセッション時間本番環境通常用 1時間緊急用 4時間検証環境通常用 2時間開発環境通常用 2時間環境セッション時間全環境 1時間本当に守るべき環境と用途のセッション時間は変えずに要件を細分化し、運用効率性を考慮し、柔軟に設計した

Slide 27

Slide 27 text

VPCフローログの分析 - セキュリティインシデントの解決 - S3からのログファイルのダウ 2チームとヒアリングを行った所感短時間作業長時間作業 slackで依頼されたらそのまま文面を受け取るだけではなくて「具体的には？」「どんなケース？」と深堀するのが大事深堀することで相手も納得しセキュリティ統制上も問題ないと判断できる着地点が見つかりやすい結局のところ人対人のコミュニケーションに行きつくので、相手のペインを解消することを大事にすると、感情的にもこちら側の要望も受け入れてもらいやすい

Slide 28

Slide 28 text

セキュリティ vs 運用効率性セキュリティ運用効率性セキュリティと運用効率性はトレードオフの関係セキュリティは企業が所有するシステムを管理する以上、絶対考慮しないといけないただ、運用効率性を度外視すると開発チームからのヘイトが高まり、最悪コミュニケーション不足の関係になることも

Slide 29

Slide 29 text

これって正解はないですよね、、

Slide 30

Slide 30 text

状況は現場に応じて異なります。運用効率性も考えて現場の声を聴いて一般的なセキュリティ指標の価値観や感覚はコミュニティなどで情報吸収することが大事と考えます。

Slide 31

Slide 31 text

まとめセキュリティ運用効率性バランスをとって、両方実現していきましょう！

Slide 32

Slide 32 text

ご清聴ありがとうございました！ JAWS-UG 彩の国埼玉支部北川卓図＠zukutakuzu