ASMを支えるエンジニアリングの舞台裏 @ GMO IERAE HackNight #3 「セキュリティプロダクト編」

ASMを支えるエンジニアリングの舞台裏 Kazuki Onishi / @0n1shi

$ whoami 大西 和貴 / @0n1shi プロダクトサービス部 部長代理 開発一課 課長 Vimmer / セキスペ / AWS SAP / etc… 前職はさくらインターネットでクラウドの中の人 低レイヤ全般、システムアーキテクチャなどについて考えたり “作ったことないもの” を作るのが好きです。 最近 Haskell 圏論 群論始めました。

はじめに

課題: 攻撃面の拡大 - ポチポチ気軽にサーバやWebサイトなどが立ち上がる - なんなら1クリックで複数コンポーネント作成される - AWS とか AWS とか AWS とか - 最近のクラウド難しい … - 開発チーム内で細々と開発が進められている自動化ツール(野良サーバ) - 絶対あるよね、心当たりある人〜 - 8080ポート開いてたりしない ? - 情シスも管理しきれないぜ …

ASMとは https://www.meti.go.jp/press/2023/05/20230529001/20230529001.html

• https://www.meti.go.jp/press/2023/05/20230529001/20230529001.html

サイバー攻撃ネットde診断 https://product.gmo-cybersecurity.com/

• https://product.gmo-cybersecurity.com/

本題

システムの全体像 クライアント ネットde診断 Web UI / API コンポーネント群 診断エンジン 脆弱性DB 今日はここの話 資産探索 サイトシール API 検証サーバ … 資産探索 資産探索 ASMだと現在3つほど開発チームがある etc … 資産探索 資産探索

診断エンジンの全体像 クライアント AWS API On-premises Queueing System VM VM VM Scanner enumeration target scanning analysis 事業やプロダクト、チームの状況やスキルセットに合わせた技 術選定やアーキテクチャを強く意識。 エンジンは精度にリソースをフォーカスさせる目的でミニマル でオーソドックスな作りとなっている。 report Vuln DB

技術スタック API: lang: Python framework: Fast API libs: - Pydantic - Pytest - SQLAlchemy - Alembic scanner: lang: Python libs: - Pytest - Boto3 既存ライブラリやセキュリティ関連との親和性の高さからPythonを採用。 「ロバストPython」いいぞ! https://www.oreilly.co.jp/books/9784814400171/ CI: GitHub Actions infra: cloud: - AWS - on-premises IaC: - Terraform - Ansible etc: - Docker - vscode / Vim # 11:1

• https://www.oreilly.co.jp/books/9784814400171/

アーキテクチャ概要 API Gateway Lambda SQS S3 ECR RDS GitHub Actions Terraform IaC以外でのリソース作成を”決して”許さない雰囲気が漂っているわせている Terraform Ansible

ロジックの実装手法 - フルスクラッチ - 特にネットワーク機器の検出や診断など - 独自パッチを施したOSSの利用 - 軽めのパッチから魔改造されてるものまで 使う使わないに関係なく気付いたものはパッチ送ったりも 有名どころだと - Nikto - WPScan その他マイナーなものもいくつか - シグネチャのみフルスクラッチ - OSS標準搭載のシグネチャをフルスクラッチでリプレイス - 人間がスクリーニングする前提であることが多い - アウトプットを再検証 - 出力された結果を再度追加で検証する

ロジックの実装まで 1. 調査 5. テスト・検証 - 公開されている脆弱性情報(CVE, NVD, JVN, Exploit DB など)の確認 - ベンダーのアドバイザリ、セキュリティブログ、研究レポートを収集 - 対象技術やサービスの仕様・挙動を調査 - 個々の処理に対するユニットテスト - 攻撃サンプルを用いた検出テスト - 正常トラフィックに対する誤検知テスト 2. 脅威分析・要件定義 6. レビュー - 攻撃手法の整理(入力パターン、リクエスト形式、プロトコル特性など) - シグネチャで検知すべき対象範囲と優先度を決定 - コードレビュー 7. リリース 3. シグネチャ設計 - 解析ロジック/シグネチャ(HTTP ヘッダ、URI、ペイロードなど)の検討 - 実装方法の決定 - ステージング環境での段階的デプロイ - 本番環境への反映 8. 運用・改善 4. 実装 - ロジック/シグネチャをエンジンに実装 特に1~3やりたい方、4~8興味あるよって方、いやもう全部やるよって方、大募集です - ログをもとに効果測定 - 誤検知があればルール調整 ペネトレからWeb,クラウド, PF/NWなど各部署との連携も盛んで 情報連携から実際のシグネチャや実装まで行ってもらうケースも。

スケーラビリティ - 累計4Mスキャン - シンプルなキューイングシステム 端的に言えばVMを横に並べるだけでスケールする仕組みとなっている(←誤解しか招かない)。 メトリクス監視やアラート通知などが設定されており、閾値も週に一度のレビュー会がある。 SQS API Auto Scale 200~ VMs

コスト最適化 - NETSCOUT/Wireshark などで発生した通信の内訳を確認 - OSSによっては内部処理以外にもキャッシュファイルの持ち方なども把握 - データベースの更新タイミングやデータフォーマットも調査 - 「こんなファイルにこういうデータもあるんだね〜」 - インターフェース経由では露出しないようなデータを発掘して使ったりもする

テスト手法 - Pytest - テストは仕様書である精神 - Unitテストから、テストサーバを用いた実際のスキャンまで可能な限り全部やる - HTTPやそのソフトウェアはもちろん、その他プロトコルのエミュレータを開発したりも - リリース前からカバレッジは常に9割以上(PRのほとんどがテストコード) ============================= test session starts ============================== platform linux -- Python 3.10.12, pytest-8.2.0, pluggy-1.5.0 -----------------------------------------------------------------------------------------------------TOTAL 11472 520 95% =========== 6704 passed, 8 skipped, 5 warnings in 2195.52s (0:36:35) =========== 2195.52s … 36m38s ある時は毎月のように GitHub Actions の実行時間を毎月食い尽くしていた時も (↑そろそろ Self-hosted しろ)

監視 - CloudWatch (AWS) / Zabbix (on-premises) - オンプレVMのカスタムメトリクスに対するコストが線形増加 - 主にオンプレを対象にZabbixへ移行 - メトリクスに設定された閾値を超えるとアラートレベルに合わせて一定間隔でSlack通知 - ログにログレベルを設定しError以上でSlack通知 週次でログ通知の要否に対する見直しをかける 過去には通知が多すぎ見過ごしが発生したりで、チャンネル 分けたり、通知頻度を見直したり、閾値見直したり日々試行 錯誤 …

サービスフィードバック サービスの一部としてアドバイザリサービスを提供しており、使い方や診断結果、セキュリティ全般に関す る質疑応答の場を月一で設けている。 前述の診断エンジンだと誤検知の調査や精度改善、製品・ソフトウェアのサポート対応、もちろんWeb UI に関連した使い勝手の部分まで、エンジニアもお客様から直接声を聞くことができる機会があり、1~2日で 実装し3日程度でリリースしたりすることも （↑もちろん、お客さんと話したいよ〜って人が参加します お客さんの生の声を聞くので、ユーザサポート/サクセスチームと同じような解像度でニーズやその熱量を 拾いサービスに反映することができます

展望

k8sやりたい - Ansibleの反映までに時間がかかる(30~40 min) - コマンド一発とは言え、ダラダラ待つのも嫌 - 宣言的でない（今の状態が見えづらい） - 動的なスケーラビリティを確保できていない - 事前にキャパシティプランニングしているが通常契約、代理店、OEM、他サービスのAPI連携など 多いところだと数千~数万ほど対象があり、場合によってはVMの追加構築が必要になる。 - 既存顧客の対象だけでもマニュアルでのリクエストに偏りがありスパイクするタイミングがある - 既にデカい物理サーバ(100 core, 400G mem)が何台かあるため有効活用したい - 多くのバッチ処理が存在する - 現状はLambda/ECS/EventBridgeあたりで実現 ずいぶん長らく小さな部署だったが、最近人が増えたこともあり よりスケーラブルな仕組みを整えたい。 実際には既に移行計画が進んでいる（俺の考えた最強の基盤

シグネチャのみの軽量アップデート 現状 - Dockerイメージをセマンティックバージョンで管理し処理やシグネチャをイメージ単位でまるっとアップデート - Pros - ロールバックがしやすい(依存関係が全てDockerイメージに閉じている) - 過去に別のクラウドからオンプレに乗り換えている - Cons - 軽微なシグネチャのみの修正でもイメージの再ビルドとデプロイが必要 - シグネチャのみの修正時はむしろオーバーヘッド(リリース作業)の方が大きい e.g. 素案 - Dockerイメージは据え置き - /opt/signatures/currentをコンテナへread-onlyマウント - Ansibleで「配布→切替→リロード」 /opt/signatures/ ├─ releases/ │ └─ 2025.08.21/ │ ├─ manifest.yaml # メタ情報（署名、ハッシュ等） │ └─ rules/... # シグネチャ本体 └─ current -> releases/2025.08.21 # 運用中を指すシンボリックリンク docker run -d ¥ -v /opt/signatures/current:/app/signatures:ro ¥ -e SIG_PATH=/app/signatures ¥ our/scanner:1.0.0

まとめ - イエラエ(CTFのイメージが強いだろうけど)開発も今アツいです...! - セキュリティ会社でありつつ開発もモダンで本格的 - GoやgRPC, GCPを採用しているプロジェクト/システムも - 技術に明るいので良いものはどんどん取り入れるし技術投資も盛ん - 脆弱性調査からインフラ/バックエンド/フロントエンド、お客様と会話したり - やりたいこと/得意なことベース(部長/課長がその哲学) - インフラのみの人 - 全部やってる人 - 開発でキャリア歩んできた方も多い - SI - ゲームメーカー - 零細ベンチャー

まとめ