【体験談】「うちは大丈夫」と思っていた個人開発サービスが攻撃された話 ─ 対策と教訓5つ | TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
小規模な個人開発サービスであっても、自動スキャンツールによる無差別なSQLインジェクション攻撃の対象となる。攻撃によりAPIのp99レスポンスタイムが大幅に悪化し、CPU使用率が限界に達するなど、サービスの可用性が著しく損なわれるリスクがある。また、ログの未整備や監視不足により、検知が遅れる点も課題である。
// Approach
ALBのアクセスログを解析して攻撃IPを特定し、NACLを用いて即時ブロックを実施。その後、AWS WAFのマネージドルールを導入することで、SQLインジェクションやXSSといった一般的な攻撃パターンを自動的に遮断する構成へと改善した。併せて、レート制限や監視アラートの設定による防御層の強化を図った。
// Result
WAFの導入により、低コストで継続的な防御体制を構築。また、ログの保存、レート制限、DB接続制限、CloudWatchによるアラート設定といった、可用性とセキュリティを維持するための基本的な運用フローを確立した。これにより、攻撃によるリソース枯渇やデータ漏洩のリスクを最小限に抑える体制が整った。
Senior Engineer Insight
> 本事例は「規模が小さいから安全」という慢心がいかに危険かを物語っている。攻撃者は脆弱性を探すために自動化されたスキャンを常時実行しており、ターゲットの重要度ではなく「開いている窓」を探しているに過ぎない。技術責任者の視点では、WAFの導入やレート制限、ログの永続化は「オプション」ではなく、サービス公開時の「前提条件」である。特に、p99の悪化を検知のトリガーとした点は実戦的だが、CloudWatchによる閾値アラートを併用することで、ユーザーからの指摘を待たずに初動を早めることが不可欠だ。コストを理由に防御を後回しにする判断は、インシデント発生時の復旧コストを考慮すると極めて非合理である。