Security-JAWS【第41回】〜Day1〜でAWS WAFの運用について発表しました！
こんにちは！ アンドパッド セキュリティグループの 宜野座(ぎのざ)です。 2026/05/16(土)に開催された Security-JAWS【第41回】〜Day1〜 にて登壇の機会をいただき、私のセッションでは「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表をしました。 今回はCfPを出した背景やセッションでお話しした内容の補足、興味深かったセッションの内容をご紹介します。 Security-JAWS にこれから現地参加したい、CfPを出してみたいと考えている方にも参考になると何よりです。 Security-JAWS について なぜCfPを出したのか CfP採択後の準備 セッションの内容について セッションでは話せなかったこと AWS WAFの新規作成 AWS WAF ルールのPriorityの順番 AWS WAFの更新作業が属人化してしまう 興味深かったセッション Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか Security-JAWS 全体を通しての感想 We are actively hiring! Security-JAWS について AWS を利用している人なら知っている有名なイベントですが、念のため紹介すると、AWSを利用する上で非常に重要な要素であるセキュリティの活用を共有して、より安全にAWSを利用することを目的として、立ち上がったイベントです。 詳しくは connpassページをご参照ください。 s-jaws.connpass.com そして今回は10周年イベントということで、改めて10周年おめでとうございます 🎉🎉 登壇者の記念Tシャツもいただきましたので、大切にします！ なぜCfPを出したのか AWSに関わる大きなイベントでもいつか発表してみたいとは思っていたのですが、なかなか挑戦できずにいました。 そんな中 3月に Security.any というイベントでも登壇の機会をいただき、せっかくの機会なので他のイベントにもチャレンジしてみようと思ったのが最初のきっかけでした。 そして以前から AWS x Security といえば Security-JAWS というくらい 多くの方が参加するイベントだと知っており、10周年のイベントには元々参加しようと思っていたのですが、もしかすると1年くらいかけて取り組んでいたAWS WAFの取り組みが発表できるのではないかと考え、CfPの提出に挑戦してみました。 CfP採択後の準備 4月にCfPの採択のご連絡をいただいて本格的に準備を開始し、CfPに提出していた登壇概要の情報からどのような内容を伝えられると参考になるだろうと1年余りの取り組みを改めて振り返りながらスライド作りに取り組みました。 スライドのデザイン統一・全体構成についての意見・分量が適切かというところではAIにも意見を貰いながら、4日前から時間を測った練習を何度か実施し、時間を大幅にオーバーしていたのでスライドを削ったり全体の時間の調整を行なうという流れで準備を進めていました。 ここまでの個人的な準備に加えて、社内でもチームの方を中心にたくさんレビューいただいて、無事発表に間に合わせることができました。 セッションの内容について 今回は1番最初のセッションの枠をいただきまして、「AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス」というタイトルで発表しました。 speakerdeck.com 準備に少し手間取ってしまい皆さまに申し訳なかったですが、会場が温かい雰囲気だったため、そこまで緊張せずに話せてよかったです。 またいくつか参考になったというコメントをXでもいただき、非常に嬉しかったです。 セッションでは話せなかったこと セッションの時間は非常に限られていたので、課題を4つに絞っていました。 そのため細かな課題はスキップしていたので、ここで一部共有したいと思います！ AWS WAFの新規作成 AWS WAFの新規作成を簡単に行えないというところも課題としてありました。 主に以下が課題の要因だったと考えています。 AWS WAFに設定するべき、マネージドルールがわからない 新規作成の時に必要な手順がわからない まずは1つ目の課題を解消するために、設定を必須とするマネージドルールのポリシーを定めていきました。 現在AWSが提供している全てのマネージドルールを確認し、未導入のものは有効性を検証の上追加したり、すでに導入されているものでも必須ではないものを除外したりという選定を行いました。 続いて2つ目の課題を解消するために、1つ目の課題解消で決めたポリシーを元にGitHubにてTemplateディレクトリを作成しました。 そしてREADMEに新規作成の手順を追加し、現在はWAFの作成依頼に対して数時間程度で対応可能となりました。(元々既存ルールの調査やコードの修正、申請などで数日かかっていました。) AWS WAF ルールのPriorityの順番 ルールはPriorityの値が小さい順に評価されますが、整理を始める前は独自 allowルール、独自 blockルール、AWSマネージドルールが様々なPriorityで設定されているという課題がありました。 そのためどのようにリクエストが評価されるかの確認がしにくかったり、追加箇所で悩むことがありました。 こちらの課題を解決するために、以下のようなルールを設けることにしました。 allowルール: Priority 0 - 49 block ルール: Priority 50 - 99 AWSマネージドルール: Priority 100 以降で設定 AWS WAFの更新作業が属人化してしまう コード化を終えたタイミングでAWS WAFマネージドルールのバージョン最新化に取り組んでいましたが、最初のうちは個人でアップグレードの対応が行われており、属人化が課題となっていました。 しかし、その後更新手順を整備したタイミング(登壇でお話しした内容)で、チームで担当者をアサインする体制に移行したことで現在はチームで分担しながら実施する運用とすることが出来ました。 コード化をしていたことで非常にスムーズにチームでの運用へ移管することができたと思います。 興味深かったセッション 今回のセッションは全部で11セッションありました。 その中からこのテックブログでは、特に私が興味深かったセッションを2つ紹介します。 他のセッションの資料も以下にアップされていますので、ぜひご参照ください。 Security-JAWS【第41回】~Day1~ 2026年05月16日(土) - 資料一覧 - connpass Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話 1つ目は、株式会社エス・エム・エス SRE 山口 隆史さんの発表になります。 2024年2月のGoogleガイドラインによって、SPF/DKIM/DMARCが必須の対応となり地道に改善を進めているというお話しでした。 SPF/DKIM/DMARCのわかりやすい説明に加えて、問題となったケースについての紹介もあり、非常に有益な内容でした。 そして改めてセキュリティの取り組みは銀の弾丸はなく、地道な運用が必要なんだと感じました。 speakerdeck.com Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか 2つ目は、アジアクエスト株式会社 足立 和生さんのセッションになります。 様々なAIツールの企業導入が進んでいますが、AWSなど他のパブリッククラウドの権限をどの範囲で許可するかは非常に悩ましい問題だと思います。 その中で、人間用のIAMロールとAI用のIAMロールを分けた方が良いよという話であったり、Claude Code / Codex / Kiro と統制観点で比較したりと興味深いお話しでした。 こちらのセッションを聴いて、改めてAIに渡している権限は今のままで大丈夫だろうか。と考えるきっかけになりました。 speakerdeck.com Security-JAWS 全体を通しての感想 イベント全体を通して、みなさんが楽しく過ごされているのが印象的でした。 そしてAWSを利用する上で学びとなる内容もたくさんあり、イベント会場も素敵でリラックスしてイベントに参加することができました。 運営のみなさま、素晴らしいイベント運営ありがとうございました！ これからもまた参加したいと思います 🙌 We are actively hiring! アンドパッドのセキュリティグループではチーム力を更に向上させて、一筋縄ではいかないセキュリティ課題への挑戦を続けていきます。 そのためにも「セキュリティ施策をどんどんリードしていきたい！」「これまでの開発経験をセキュリティ分野で活かしてしてみたい！」など、多様なバックグラウンドをお持ちの方と一緒に働きたいと考えています。 カジュアル面談もいつでも大歓迎ですので、ご興味がある方はぜひ以下より申し込みお待ちしております。 hrmos.co またその他にも、さまざまなポジションを募集していますのでご興味がある方はぜひご参照ください。 hrmos.co
- AWS
- セキュリティ
- IaC
Lambdaランタイムの更新をRenovateで検知できるようにしました
こんにちは、SREの千明です。2020年1月に入社して、気づけば7年目に突入しました。 最近SREでは、イベント参加やブログ執筆が活発になってきているので、私もそれに触発されて久しぶりにブログを執筆することにしました。前回ブログに投稿したのが2020年6月だったので、なんと約6年ぶりの投稿になります。 WordPressをShifterへ移行した話 - ANDPAD Tech Blog 今回は最近導入した「Lambdaランタイムの更新をRenovateで検知できるようにする仕組み」について紹介しようと思います。 こんな方におすすめの内容です 今回の内容は、以下のような方向けになっています。ぜひ参考にしていただけると幸いです。 TerraformでLambda関数の管理をしていて、ランタイム更新を自動検知したい方 Renovateをすでに導入済みでパッケージ自動検知、更新に利用されている方（Renovateの導入方法は説明しません） 複数のLambdaランタイムが混在しているリポジトリを管理されている方 何を解決したかったのか この仕組みを導入する以前は、以下の手順で定期的にLambdaランタイムの更新を実施していました。 Lambda runtimes(英語版)のページを定期的に確認して、EOLが間近に迫ったLambdaランタイムがないか確認する。 EOLが間近に迫ったLambdaランタイムがあった場合、該当のLambdaランタイムを使用しているLambda関数をリストアップする。 リストアップしたLambda関数を管理している開発チームへLambdaランタイムの更新を依頼する。 各開発チームが開発環境でLambdaランタイム更新の動作検証を行い、問題なければ本番環境でもLambdaランタイムの更新を実施する。 しかし、上記の方法では誰かが能動的にEOLの確認をしなければいけません。さらに、EOLを基準として動き始めるため、更新期間（移行のための準備期間）が短くなってしまいます。Lambda関数を多数管理している開発チームの場合は、期限日（Deprecation date）までに更新が間に合わないこともあります。 この課題を解決するために、新しいLambdaランタイムがリリースされたタイミングを自動検知して、更新を始められるようにしたいと考えました。まず、更新タイミングを自動検知することによって、能動的に確認をする必要がなくなります。そして、更新を始めるタイミングをEOLからリリースにすることで、更新期間を長く取ることができて、余裕を持ってLambdaランタイムを更新できます。 どうやって解決したのか 上記の課題を解決するために、Terraformで管理しているLambdaランタイムのバージョンをRenovateで検知して、新しいバージョンがリリースされたタイミングでPRを作成するようにしました。以下でその方法を解説します。 リポジトリ構成 今回サンプルとして用意したリポジトリは以下のような構成になっていて、lambda_function_rubyとlambda_function_nodejsの2つのLambda関数を管理しています。（ソースコードは別で管理されていて、今回の説明では割愛します） . ├── lambda_function_ruby │ └── main.tf ├── lambda_function_nodejs │ └── main.tf ├── modules │ └── lambda_function │ └── main.tf └── renovate.json いくつかのファイルについても、簡単に説明します。まず、modules/lambda_functionは、Lambda関数に必要なリソースを定義するモジュールで、runtimeの値を変数で受け取るようになっています。例えば、lambda_function_rubyでは、以下のようにモジュールを呼び出して、ランタイムの値を指定しています。 module "lambda" { source = "../../../modules/lambda_function" runtime = "ruby3.3" } また、すでにRenovateが導入されていて、その内容はrenovate.jsonによって設定されています。今回は、Terraformを更新するだけのシンプルな設定になっています。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": [ { "matchManagers": ["terraform", "terraform-version"], "labels": ["dependencies", "terraform"] }, { "matchPackageNames": ["hashicorp/terraform"], "additionalBranchPrefix": "{{packageFileDir}}-", "groupName": "terraform-version", "versioning": "hashicorp" }, { "matchDatasources": ["terraform-provider"], "additionalBranchPrefix": "{{packageFileDir}}-", "groupName": "terraform-providers" } ] } 説明は以上にして、次からはlambda_function_rubyを使って、Lambdaランタイムの更新をRenovateで検知できるようにするための設定方法を解説していきます。 Terraform側の設定 まずは、Terraform側のLambda関数のリソース定義にあるruntimeへ、以下のようなRenovate用のコメントを追加します。このコメントを元にRenovateが更新対象を抽出します。 module "lambda" { source = "../modules/lambda_function" # renovate: datasource=endoflife-date depName=aws-lambda versioning=loose runtime = "ruby3.3" } Renovate側の設定 次に、renovate.jsonにcustomManagersを追加します。この設定によって、先ほど追加したコメントとLambdaランタイムの設定を抽出します。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": ["...Terraformの設定（省略）..."], "customManagers": [ { "customType": "regex", "description": "Update AWS Lambda runtime in Terraform files", "managerFilePatterns": ["/.+\\.tf$/"], "matchStrings": [ "#\\s*renovate:\\s*datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s*runtime\\s*=\\s*\"(?<packageName>[a-z]+)(?<currentValue>[0-9.]+)(\\.x)?\"" ], "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{/if}}" } ] } このとき、正規表現の名前付きキャプチャーグループで名前を付けた値が、後述するpackageRulesの設定で利用できます。 そして、ここが今回のミソなのですが、packageNameにrubyが入るようになっていて、この値もpackageRulesの中で利用できます。 次に、先ほどのcustomManagersで抽出した部分を修正するために、packageRulesに2つのルールを追加します。このリポジトリでは、RubyとNode.js、2つのLambdaランタイムを管理しているので、それぞれのLambdaランタイムに対してルールを追加しています。 { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "packageRules": [ "...Terraformの設定（省略）...", { "matchDatasources": ["endoflife-date"], "matchDepNames": <span class="synS
- AWS
- Lambda
- Terraform
- Renovate
- SRE
浮いたボールを拾いまくったらトイルを改善していた話
こんにちは。 サービスプラットフォーム部 SRE チームの谷合です。 普段はメガネ集めと、毎日のビールを楽しみながら生きています。 2025年11月に入社してから今日まで、浮いているボールや浮きそうなボール、あるいはすでに落ちているボールを拾うことを、意識的にやってきました。 ちなみに、あとから振り返ってみると、その姿勢の背景には、Kyash 執行役員 VP of Engineering の Konifar さんの記事の影響があったように思います。 「ボールは落とさない」という考え方に以前から強く共感していましたが、入社後はそれを一段階進めて、「なら拾いにいこう」と思ったきっかけが、まさにこの記事でした。とてもいい記事なので、皆さんも是非ご覧ください！ konifar-zatsu.hatenadiary.jp 今回のブログでは上記のKonifarさんの記事をもっと紹介したいところですが、私が入社後どんなボールを拾って、どんな結果になったかをご紹介します。 拾ったボール 拾った結果 トイル解決へ 依頼を見える化 プロファイルの送信自動化 さいごに We are hiring! 拾ったボール SREチームは、日頃から様々な依頼を他チームや他部門から受けることがあります。 SREチームは割り込みタスクが発生しやすく、タスクが業務時間から溢れてしまいがちです。効率よく捌いたり、発生そのものを抑制する努力が大切です。 ですので、新入社員の私は先輩社員をサポートするためにボールを拾いまくる決断をしました。 そんな私が感じたのは SREチームの新入社員こそ浮いたボールを拾った方が良い ということでした。 自発的に課題を見つけて倒しに行く過程で、既存SREメンバーやその他の社員にとっては当たり前のことでも、新入社員の視点から見ると トイル であると気付くことができます。 また、浮いたボールを拾いまくることで、現状の歴史的経緯やコンテキストにも多く触れることができ、自身の成長にも繋がります。 実際に拾ってきたボールを、定常業務の巻取りと、参加する過程で見つけた改善のボールに分けて記載します。 まず、定常業務は浮いていたわけではありませんが、依頼量が多くて大変だったため、積極的に参加しました。 AWS IAMユーザやグループ追加 GitHubリポジトリ、チーム追加 SREチーム内のコードレビュー 定例会議のファシリテーション ベトナム法人 ANDPAD VIETNAM (アンドパッドベトナム) のエンジニアのIaCレビューもしくはインフラ実装 一方で、参加する過程で「ここは改善できそうだ」と感じた部分は、浮いていた課題としてボールを拾って対応しました。 拾った結果 現在、弊社ではIAMユーザからAWS IAM Identity Centerに移行し、さらにIdPと連携させることでSSOへの移行を進めています。 しかし、まだ完全移行が完了していないため、前述したようにAWS IAMユーザの払い出しやグループへの追加申請は、SREの業務を圧迫することがよくありました。 各種アカウントやユーザ発行、グループ追加などの申請業務フローにSlackワークフローが使われていて、１つのチャンネルに様々な依頼が集まっています。 そのため、月末月初の入退社対応、開発に必要な権限払い出しや、グループ追加、GitHub関連の依頼が集まるチャンネルはカオスな状態でした。 このチャンネルにくる依頼の難しいところは、SRE以外のチームが対応する依頼も含まれるといったことです。 そんな無数の依頼に対して、SREチームはチャンネルを自発的に見に行き、対応すべき依頼を目視で見つけている状況でした。 申請が羅列されているので、SREチームが対応すべき依頼を探すのが大変だったため新入社員の私はこれを何とかできないかと考えました。 さらに、IAMユーザの払い出し後は初期プロファイルを手動でDMしていました。 加えて、弊社ではAWSで二要素認証を必須としているため、DM後にその設定がうまくできない人からの個別問い合わせが日本とアンドパッドベトナム両方で発生していました。 これらが結構なトイルとなっていたのです。 SREチームの稼働を圧迫していたボールを拾いまくった結果、以下のトイルが見えてきました。 SREの対応すべき依頼を見つけるための目視 IAMユーザの初期プロファイルを手動DM 二要素認証の設定個別対応 トイル解決へ 見つけたトイルに対して私は以下のアプローチをとりました。 依頼を見える化 当初、 SREチームが対応すべき依頼を目視確認 している状況について、以下のように一覧を自動作成する改善を検討しました。 対応すべきタスクを Slack リスト化 対応すべきタスクをスプレッドシート化 ところが、弊社の依頼が集まるSlackチャンネルのワークフローが作成する投稿のメッセージでは、リアクションをトリガーにできませんでした。 また、アンドパッドベトナムのエンジニアは独自のSlackワークスペースを持つため、このチャンネルにSlack Connectで接続しています。 Slackの仕様上、 外部の人が参加しているチャンネルではキーワードトリガーは設定できないため、 SRE といったキーワードを持つ依頼をトリガーにできませんでした。 そこで、「一覧の自動作成」以外の道を模索すべく、チャンネルの管理者にコンタクトをとり、一緒にソリューションを検討しました。 まず、弊社の依頼は以下のフローで処理されていました。 依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される 依頼を上席が承認する 管理者が投稿をSREに依頼する 目視で確認すべき数が多いため、対応漏れが発生する そこで、以下のようにチャンネルの管理者に変更してもらい、SREが対応すべき依頼をfeedとして集約することで可視化できました。 このフローは今では上手くいってますが、SREから細かくFBをしてチャンネル管理者と一緒に連携してオペレーションを変更するなどして作り上げていきました。 依頼者が専用のワークフローで依頼すると、チャンネルに依頼が投稿される 依頼を上席が承認する 管理者が投稿をSREに依頼する SRE用の依頼を、別の feed チャンネルへ通知投稿するワークフローが動く feedの通知投稿には、依頼元投稿と依頼元スレッドリンクが記載される 依頼元で 対応する ボタンを押すと対応者の名前がメンションされ、通知投稿に 対応中 スタンプが自動で押される 対応後は 対応しました ボタンを押すと、通知投稿に 対応完了 スタンプが自動で押される このようにSREだけでなく、他チームにいるSlack管理者を巻き込んで 会話 でトイルを解決しました。 また、このフローの副次的なメリットも生まれました。 以前は1つの依頼に対してオーナーを可視化する術がなかったので、依頼が対応中であることを知らずに複数の担当者で対応してしまうことが発生していました。 今回のフローに変更することで対応者の名前がメンションされることでオーナーが可視化でき、2重対応がなくなりました。 プロファイルの送信自動化 ここまでは申請をどのように可視化するかという問題に対して、目視によるトイルを他チームと連携して会話で解決するアプローチをご紹介しました。 ここからは、 IAMユーザの初期プロファイルを手動DM をどのように自動化してトイルを倒したかをご紹介します。 アンドパッドでは、IAMユーザはTerraformで管理しているのでコードを開発者に書いていただき、PRを起票いただくことでユーザを払い出しています。 その後、以下のフローで後処理を手動で実施していました。 初期パスワードをマネジメントコンソールで作成 初期パスワードとIAMユーザ名、マネジメントコンソールのURLをSlackへDM 毎月の月初には日本のみならずアンドパッドベトナムの新入社員のIAMユーザ払い出しが発生するため、累計するとそれなりに時間を要する作業でした。 さらに、人間がDMで初期情報を送っていたため、二要素認証の設定でつまずいたユーザーはそのDMで直接問い合わせてくることが多く、SREメンバーへの個別対応が頻発していました。 これを技術の力で解決しました。 まず、IAMユーザを作成した時に、CloudTrailで CreateUser イベントが発生します。これを Amazon EventBridgeで検知します。 Amazon EventBridgeはAWS Lambdaをトリガーし、以下の流れで処理を行います。 アンドパッドのポリシーに沿ったパスワードを、初回ログイン時の変更を強制した上で文字列として作成 aws/aws-sdk-go-v2パッケージのCreateLoginProfile関数でパスワードを登録 AWS Systems Manager Parameter Storeに事前登録したSlack Bot Tokenを読み出す slack-go/slackパッケージを使用し、Slack Bot経由でDM シーケンス図で書くと以下のようになります。 この仕組みのおかげで、IAMユーザの作成後は以下のDMが自動送信できるようになりました。 なお、弊社は日本だけでなく、アンドパッドベトナムもあるため、日本語と英語を併記しています。 Bot経由の自動送信に切り替え、メッセージ内で「問題が発生した場合は申請スレッドで問い合わせてください」と案内することで、問い合わせがオープンな場に集約され、個別DM対応のトイルも解消しました。 この自動化を実装したことで、SREは余剰の時間を別のタスクへ充てられるようになり、チームの生産性も改善しました。 さいごに ここまで私がボールを拾いまくって、いつの間にかSREチームの長年のトイルを「会話」と「技術」で解決した話をご紹介しました。 ボールを拾うのはとても勇気が必要ですし、「できなかったらどうしよう」とか「自信がないな」とか色々と考えて一歩踏み出せないですよね。 でも、拾った先には所属チームから感謝されるし、自分の成長にも繋がります。何よりも数をこなすことで誰も気づかないチームの問題点にも気づくことができるようになります。 ボールを拾って、問題点を解決するなんて素敵なアクションにも繋がるので、是非臆せずに行動してみてほしいです。 浮いたボールにはチャンスがあるぞ！ We are hiring! アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。 hrmos.co hrmos.co hrmos.co github.com
- SRE
- AWS
- Slack
- 自動化