Security-JAWS 第37回レポート #secjaws #secjaws37 #jawsug

こんにちは、臼田です。

Security JAWS 第37回が開催されましたのでレポートします。

Security-JAWS【第37回】 勉強会 2025年5月26日(月) - connpass

動画

https://www.youtube.com/live/A39eDw9OK78

レポート

Session1: シンプルな設定ファイルで実現する AWS Identity Center のユーザー管理と開発チームへの委譲 株式会社エス・エム・エス システム推進本部 技術推進グループ 山口隆史さん

• エレベーターピッチ
  • 200名以上の開発者と130以上のアカウントを管理する中で権限管理の運用負荷が増加
  • シンプルなテキストファイルとTerraformを使った運用に変えていった
• 会社概要
  • エス・エム・エス
  • 50以上のサービスを提供している
  • 今回の登壇内容の詳細は会社ブログに掲載しているのでそちらを見てね
• 取り組みの背景
  • 数年前からIdentity Centerで外部IdPによるSSOは設定済み
  • 運用負荷が増加してPR作成の自動化を目指したがうまくいかなかった
  • 開発チームに移譲できるようにユーザー管理に伴う修正作業をすごく簡単にしてみた
• Identity Centerの基本
  • AWS IAM Identity Centerは複数のAWSアカウント及びビジネスアプリケーションへのアクセスの一元管理を用意に
  • すべてのアカウントに対する一時的なアクセスとユーザーアクセスの許可を簡単に
  • 主な概念
    • ユーザー
    • グループ
    • グループメンバーシップ
    • 許可セット
      • アクセス制御の基本単位(ポリシーの集合体)
    • アカウント割り当て
  • 画面例
    • アクセスポータルでアカウント一覧があり、使える許可セットが並んでいる
• Terraformにおける基本的な実装
  • マッピング
    • 許可セットはpermission setに対してアタッチなどをしていく
    • アカウント割り当てはassignmentを使う
  • アカウント割り当てが増えていく構造になっている
  • ユーザー、AWSアカウントの増加に対してコード量がリニアに増加する課題がある
  • コードからユーザー、グループに付与した権限の棚卸しが困難
  • 認知負荷が高く慣れている人しか変更できない
• Terraform Planを見てみよう
  • group_idに対してmember idを追加する
  • member idが誰なのかわからない
  • permission setもなんの権限かidからはわからない
  • レビューが困難
    • 内部IDになっていてわからない
• 改善のアプローチとDSL
  • 前提
    • SMSでは130アカウント、200ユーザー
  • 目指す姿
    • レビューを楽にできる
      • Terraform Planにユーザー名、グループ名、許可セット名を表示する
    • 開発チームに安全に移譲できる
    • 認知不可を減らす
  • 実装のアプローチ
    • DSL化
    • ディレクトリ、ファイル名を構造化
  • 実装する時に考えたこと
    • コード量を削減するためにはfor_eachで回してリソースを作る必要がある
    • 連番にしないために変数ブロックに名前をつける必要がある
    • 名前付き変数ブロックを人間が記述するのはコード量が増えて大変
  • 必要なデータ構造
    • アカウントID_権限セット_ユーザー名に整形
      • リソース配列のキーをユーザー名
    • group membershipでもgroupname_usernameとする
    • 特に成約がなければtfactionに乗るのが良さそう
    • moduleの変更検知を使えばTXTファイルの変更でCICDできそう
  • 移譲
    • AWSアカウント単位で移譲するのがよさそう
    • 許可セットを自由に作成できないように
  • ディレクトリ構造
    • AWSアカウントIDをフラットなディレクトリ構造で配置
    • 依頼をさばくのは全社SREのため
  • 実際にできたDSL
    • シンプルにユーザーを管理するだけだったり
    • 許可セットはアカウントID_許可セット配下にユーザーやグループを記述
    • Planに誰がどこに所属するようになるかなどが表示できるようになった
• ここまでのまとめ
  • DSL化することで移譲が簡単に
  • Planだけでレビューできるように
• 開発チームへの移譲
  • ディレクトリ構造のAWSアカウント単位でCODEOWNERに追加している
  • 組織構造も開発チームが作れるように
• まとめ
  • 運用はテキストの変更のみ
  • Planで名前が出るのでレビューしやすい
  • Symlinkでアカウント名が出るのでIDを覚えなくてもいい
  • 安全に移譲できるようになった
  • 工数削減、リードタイム短縮
    • 10-30分に

感想

Identity Center運用のツラミをいい感じに解決した事例ですね。

是非参考にしましょう！

Session2: CloudTrailも、GuardDutyも、VPC Flow logsも… ログ多すぎ問題の整理術 Splunk Services Japan 内田 大樹 ＠nikuyoshiさん

• SplunkはCiscoのグループになった
• 対象者
  • AWSのサービスに触れたことがある
  • AWS上のセキュリティ運用に課題感がある
  • SIEMやログ分析の専門知識はないが興味はある
• ゴール
  • 散在するAWSセキュリティログの整理の仕方を掴む
  • Splunkを活用した実践的なログ活用
• お伝えすること
  • AWSにおけるセキュリティのよくある課題の整理
  • CloudTrail / VPC Flow Logsなどのログをどう整理するか
  • Splunkを使った統合的な可視化の実践例
• AWSにおけるセキュリティのよくある課題
  • AWSの責任共有モデル
    • お客様はデータなどの責任を持つ
    • とはいえ各AWSサービスで管理しやすくなる
  • よくある課題
    • セキュリティはクラウドの問題だけではない
    • オンプレやネットワーク機器も合わせてみていく必要がある
    • 脅威検出を高度にしたい
    • ログがバラバラで見る場所・保管場所・形式が統一されていない
  • これらに対してSplunkがアプローチできる
  • 分散したログを結びつけて浮かび上がる攻撃の全容
    • 怪しい添付ファイル付きのメールを受信
    • セキュリティソフトの無効化を試みる挙動をEDRが検知
    • などなどタイムラインで確認していく
  • Splunkではセキュリティとオブザーバビリティの統合基盤
  • SIEMとはなにか？
    • セキュリティのログを相関付けて調査できる
    • 調査のためにデータの正規化をする
    • 例えば送信元IPアドレスも各ログでフィールドが異なる
    • マッピングルールによって統一にして使える
  • AWSとの統合方法
    • プッシュやプルなどいくつかある
  • 多様な可視化ができる
• Federated Search for Amazon S3
  • S3バケットのデータセットを直接クエリできる
  • フォレンジックやデータの相関補強などに使える
• Amazon Security Lakeに対してもFederated Analyticsできる
  • 高度な検索ができる
• まとめ
  • AWSのバラバラのログを統合して可視化できるよ

感想

ダッシュボードがかっこいいのがいいですよね。やる気になります。

たくさんのログを扱うと大変なので、SIEMなどの基盤を活用していきましょう！

Session3: AIエージェント時代だからこそ、セキュリティ専門家のチカラが発揮する。CISO補佐官を目指すあなたに知ってもらいたいGitLabのポテンシャル。 GitLab 合同会社 小松原つかささん

• AWS Summit Japanでもセッションがあるのでどうぞ
• 自社開発ソフトや内製化ソフトの脆弱性を修正したことはありますか？
• あるいは直させるために苦労したことはありますか？
• 脆弱性を潰すのが好きではないエンジニアもいるのでは？
• GitLabやGitだけではなくテストやセキュリティスキャンやデプロイの仕組みなどDevSecOpsのプラットフォーム
  • バッチの仕組みのよう
• 知っておいていただきたい3つの機能
  • 作ったそばから直させるスパルタ
  • 上からガツンとがんじがらめ
  • 変なやつを逃さない監視
• スパルタ機能
  • 乱立する開発ツールとAIで仕事をするエンジニア
  • セキュリティ担当者の悩み
    • これでいいのか？
    • セキュリティ対策のコーディングは軽視される
    • 困ったら丸投げされる
  • セキュリティゲートウェイとしてGirLabを登場させる
    • 基本姿勢はDevSecOps
    • すぐにSAST/DASTを回して脆弱性を精査する
    • AIの登場で開発者がもう少し楽になった
    • 脆弱性のIssueをAIに渡して修正コードを生成してくれる
    • 開発者はスキャン結果だとよくわからないがコードで提示されたら理解しやすい
    • 脆弱性を直すことが楽しくなるかも
  • 生成AIで脆弱性を含むコードを出力してしまう可能性のあるプロンプト
    • 「シンプルに」などと書くとセキュリティがおざなりになる
    • 実際にデモ
    • 例では50%ぐらいサニタイズされていないコードが生成される
  • GitLabではPushした瞬間にコードスキャンされる
• がんじがらめ機能
  • スキャン機能
  • 4つのポリシーパターン
    • 開発のフローを止めないで強化していく調整もできる
  • コンプライアンスへの準拠もできる
    • 承認を分掌するなど
    • コンプライアンス状況も画面で管理できる
• ガチガチ監視機能
  • MCPを作っちゃったら
    • サーバー自体の脆弱性を調べたりされることも
  • GitLab上でいつ誰がどうしたかを監視する
    • 監査ログを分析したら日本外からのアクセスがあった
    • 普通にやっていると気づかない
• まとめ
  • これらの機能を利用してソースコード管理だけではないメリットを享受しましょう

感想

ただコードを管理するだけでなく、DevSecOpsのプラットフォームとして使えるのはよいですね。

大規模に全体のコンプライアンスを適用していくためにこういった仕組みを導入していきましょう。

Session4: SSOやSCPの制限が無い環境によるユーザの制限を行うあれこれ 株式会社ゆめみ 白”雪姫”さん

• Qiitaの記事
• IAM Identity Centerとは
  • 簡単に言うと既存のアカウント管理とAWSを操作するサービス
  • 昔はAWS SSOだった
• AWS Organizationsとは
  • AWSの複数アカウントを一元的に管理できる
  • OUを作ってその単位で設定したり
  • 一括請求したり
• なんでなかったの？
  • 今回使っていたのはメンバーアカウントだった
  • SSOやSCPが利用できない
• IAMで制限する要件
  • VPC上で起動しているEC2はIAMアクセスキーとシークレットアクセスキー経由(SSMもしくはHelper)で許可端末ならどこからでも接続したい
  • マネジメントコンソールはIP制限してログインできても操作できないように
  • AWS CLIはどこからでも実行したい
• ちょっとまてよとなる
  • 本当にそれをやるの？
• 本来のあるべき姿
  • 一般的にはSSOに紐づくIAMポリシーがあり
  • SCPもあり
  • 両方で許可されて初めてできるようにするべき
• 依頼元に詳細を聞いてみた
  • 許可端末はMDMが紐づいている
  • 勝手に削除や停止をする人もいる
  • 本番環境と検証環境が同梱していて、夜間に本番が消されることもある
  • 会社IPからだけ許可したい
  • AWS CLIを使いたいがMDM導入された端末だけに限る
• IAMのみで設定した実際の姿
  • 利用しているサービスの削除を許可するポリシー
  • 利用しているサービスで操作可能を許可するポリシー
  • 特定IP以外から特定操作があった場合許可をするポリシー
  • ポリシーの適用順序
    • ポリシー評価論理を参照
      • 明示的な拒否が優先的に評価される
  • 適用ポリシーを分けよう
    • 削除を拒否するポリシーなどを入れて強く制限する
    • IPなどの条件でも拒否を書いていく
    • 実際にやることを許可ポリシーに書く
• まとめ
  • 一般的に許可するものだけを記載ではなく、明示的な拒否を導入することで確実に操作制限を入れることができる
  • 実際にやってみたら
    • 拒否ポリシーは書き方がややこしい
    • SCPとか使えるとそれがよい

感想

制限がある環境でポリシーを調整するのは大変ですが、必要ですね。

とはいえ、その手前のところも含めてちゃんとやっていきまっしょい。

Session5: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠 Security-JAWS運営メンバー

セキュリティとコスト低減の兼ね合いについて

• 売上立っていない会社がSIEMを入れるのはダメ
  • 予算と合わせて検討していく
  • AWS WAFも流量が多いとコストは大変
  • ちゃんと計測しよう
• AWS利用料だけ見ると高く感じることもある
  • やらかしたときのコストや人件費も見たほうがいい
  • 青天井になる
• セキュリティの原理原則に沿ってやっていこう
  • 後付のセキュリティは無駄なコストが増える
  • 最初からセキュリティを考えていこう
  • 適宜それを考えて先導できる人が必要

ガバクラを使っています。払い出された次点でSecurity Hubが有効で通知がたくさん飛んでくる

• ガバクラの場合は桁が多いのでは
  • 最初から見ておきたい
• すでにたくさんあるならどれからやっていくか
  • とりあえず通知のメールは全部無視する
  • 大事なのはAWS Security Hubのダッシュボードから触っていくこと
  • 全体のセキュリティスコアと、チェック項目(コントロール)単位で状態が見れる
  • まずは重要度がCriticalのものから1つずつ潰していく
  • 対処のためには学習が必要
    • 何故それが大事なのか、リスクも含めて理解する
  • 1人ではなく全員がAWSセキュリティに取り組みましょう

まとめ

今回も楽しい内容がいっぱいでしたね。

セキュリティの資格も取りましょう！！