AWSにWebアプリをデプロイしたら、セキュリティ対応って何をすればいいの?

はじめに

AWSにWebアプリケーションをデプロイして、無事に動き出した。めでたい。……のですが、そこでふと不安になります。

「セキュリティ対応って、何をすればいいんだろう?」

セキュリティグループ(通信の許可設定)は絞った。HTTPSにもした。パスワードも強くした。でも——

• 誰かに不正アクセスされていても、気づける自信がない
• 使っているライブラリに危険な欠陥が見つかっても、知る手段がない
• どこかの設定をうっかりミスしていても、誰も教えてくれない

この「何かあっても気づけない」状態が、デプロイ直後のAWS環境の実態です。

私のチームも同じ状態からスタートし、AWSのセキュリティサービス3つを導入して「気づける体制」を作りました。この記事は、そのときに整理した考え方をまとめたものです。

• 前編(本記事): 何から守ればいいのか、どのサービスが何をしてくれるのか、お金をかけずに始めるにはどう絞ればいいのか——考え方をとことん丁寧に
• 後編: 決まった構成をAWS CDKでコード化する手順書(コード付き)

初めてセキュリティ対応を任された方を想定して書いています。前編にコードは一切出てきません。読み終わる頃には「なるほど、まずこれをやればいいのか」と具体的にイメージできる状態を目指します。

この記事の前提

• AWSアカウントを1つ持っていて、そこにWebアプリをデプロイ済み
• セキュリティグループ(通信の許可設定)・HTTPS・IAM(権限管理)は、ひとまず設定してある

1つだけ先回りさせてください。もしルートアカウント(AWSアカウント作成時に作られる最上位のアカウント)のMFA(多要素認証)がまだなら、この記事の内容より先にそれを有効化してください。無料で、数分で終わって、効果はこれから紹介する3サービスより大きいです。

なぜ「セキュリティ対応」はこんなに分かりにくいのか

最初につまずくのは、技術ではなく言葉の大きさです。「セキュリティ対応をしてください」と言われても、範囲が広すぎて何を指しているのか分かりません。地図がないまま「安全にしておいて」と言われているようなものです。

なので、最初にやるべきことは製品選びではありません。「何から守るのか」を分類することです。分類してしまえば、それぞれに対応するAWSのサービスがきれいに当てはまり、話は一気にシンプルになります。

この記事では、その分類から始めます。

あなたのAWS環境を「家」にたとえると

分類の前に、現在地を確認しましょう。デプロイ直後のAWS環境を家にたとえると、こうなっています。

すでにやっている対策(=戸締まり)

AWSでやったこと	家にたとえると
セキュリティグループで通信を制限	玄関に鍵をかけた
HTTPS化	手紙をハガキではなく封筒で送るようにした
IAMで権限を管理	合鍵を渡す相手を決めた

どれも大事です。でもこれらはすべて「入られないようにする」対策、つまり戸締まりです。

足りていないもの(=見張り)

• 泥棒が入ったことに気づく仕組み(防犯カメラ)がない
• 家の設備が古くなって危なくなっていないか点検する仕組みがない
• 窓の閉め忘れをチェックする仕組みがない

つまり今の状態は「鍵はかけたけど、誰も見張っていない家」です。鍵がどんなに立派でも、破られたことに気づけなければ、被害は静かに拡大し続けます。実際、セキュリティ事故で怖いのは「侵入されたこと」そのものより「侵入されてから数ヶ月間、誰も気づかなかった」ことだったりします。

これから作るのは、この「見張り」の仕組みです。

守るべき脅威は、たった3種類

「見張るべきもの」は無数にあるように思えますが、実は3種類に分類できます。この3分類が本記事でいちばん大事な考え方です。

① 攻撃・不正アクセス — 「泥棒が入る」

外部の誰かが、あなたの環境に悪さをしにきます。

ありがちな事故: 開発者のアクセスキー(AWSを操作するためのパスワードのようなもの)がうっかりGitHubに公開され、それを拾った攻撃者が勝手に高性能サーバーを大量起動して仮想通貨の採掘に使う。気づいたときには数十万〜数百万円の請求が来ている——これは昔から現在まで、本当によく起きている事故です。

他にも、データベースへのログイン試行の総当たり、S3(ファイル置き場)からのデータ持ち出しなど。共通するのは「起きたことにいち早く気づく」ことが対策になる、という点です。泥棒を100%防ぐことは誰にもできませんが、入った瞬間に気づければ被害は最小で済みます。

② 脆弱性 — 「建材の欠陥が後から見つかる」

あなたのアプリは、たくさんのライブラリ(他人が作った部品)の上に成り立っています。その部品に、後から重大な欠陥(=脆弱性)が見つかることがあります。

ありがちな事故: 世界中で使われている有名なライブラリに重大な欠陥が公表される。攻撃者は公表直後から、その欠陥が残っているサーバーを世界中で機械的に探し回る。対応が数日遅れただけで侵入される——数年前に世界中を大騒ぎさせたログ出力ライブラリの欠陥(いわゆるLog4Shell)がまさにこれでした。

怖いのは、デプロイした時点では何も問題がなかったことです。家を建てたときは合法だった建材に、後からリコールが出るイメージです。つまり一度チェックして終わりではなく、「新しい欠陥情報が出るたびに、自分の環境に該当がないか照合し続ける」必要があります。これを人手でやるのは不可能です。部品は数百個あり、欠陥情報は毎日世界中で公表されるからです。

③ 設定ミス — 「窓の閉め忘れ」

攻撃でも欠陥でもなく、自分のうっかりです。

ありがちな事故: S3バケット(ファイル置き場)の公開設定を誤り、顧客情報が誰でも閲覧できる状態になっていた。ニュースになる情報漏えいの多くは、高度な攻撃ではなくこの単純な設定ミスが原因です。

AWSの設定項目は膨大で、しかも日々の運用で変わり続けます。「先月は大丈夫だった」は何の保証にもなりません。これも「継続的に自動チェックし続ける」しかない領域です。

3分類のまとめ

#	脅威	家にたとえると	必要なこと
①	攻撃・不正アクセス	泥棒が入る	起きた瞬間に気づく(検知)
②	脆弱性	建材に後からリコールが出る	欠陥情報と照合し続ける(予防)
③	設定ミス	窓の閉め忘れ	自動で点検し続ける(点検)

ポイントは2つです。

1. この3つは性質がまったく違うので、1つの道具では守れない
2. どれも「継続的に・自動で」やるしかない。人手による頑張りでは成立しない

その3つに、AWSのサービスがきれいに対応する

ここまで整理できると、話は急にシンプルになります。AWSには、この3分類に1対1で対応するサービスが用意されているからです。

Amazon GuardDuty = 防犯カメラ+警備員

AWS内の各種ログ(誰がいつ何を操作したか、どんな通信が発生したか)を、AWS側が機械学習で分析し続け、「怪しい動き」を見つけたら知らせてくれるサービスです。

• 盗まれたアクセスキーによる不審な操作
• データベースへの不審なログイン試行
• ファイル置き場(S3)への普段と違うアクセス

こういったものを検知します。最大の特徴は、スイッチを入れるだけで動くことです。カメラの設置工事(エージェントのインストールやログの設定)は一切不要。「まず何か1つだけ」と言われたら、私はこれを勧めます。

Amazon Inspector = 住宅の定期点検

あなたのコンテナイメージやLambda関数(=アプリの部品一式)を継続的にスキャンし、既知の欠陥(脆弱性)が含まれていないかを照合し続けるサービスです。

大事なのは「継続的に」の部分です。デプロイ時に1回チェックするのではなく、世界のどこかで新しい欠陥が公表されるたびに、手持ちの部品に該当がないか自動で再照合してくれます。「建材のリコール情報を毎日チェックして、わが家に該当があれば教えてくれる点検業者」です。

AWS Security Hub = 管理人室

2つの仕事をしてくれます。

1. 戸締まりの自動点検: AWS公式のチェックリスト(「S3が公開されていないか」「暗号化が有効か」など数百項目)に沿って、設定ミスを継続的にチェック
2. 報告のとりまとめ: GuardDutyとInspectorが見つけたことも、自動的にここへ集まる

2つ目が地味に重要です。サービスを3つ入れると「見る画面が3つに増えて大変そう」と思いますよね。実際はSecurity Hubが管理人室になり、あなたは1つの画面を見るだけで済みます。

よくある疑問に先回りして答えます

Q. WAF(Webアプリのファイアウォール)を入れているから十分では?
WAFは玄関前の警備員で、Webサイトへの攻撃という「入口の一部」を守る道具です。盗まれた鍵での正面からの侵入(①)、部品の欠陥(②)、窓の閉め忘れ(③)には無力です。役割が違うので、置き換えにはなりません。

Q. この3つを入れたら、もう安心?
「気づける」ようにはなりますが、気づいた後に対応するのは人間です。防犯カメラは泥棒を捕まえてはくれません。ただ、対応のスタート地点が「数ヶ月後に偶然発覚」から「15分後に通知」に変わることの価値は計り知れません。

Q. 難しい設定が必要?
本質的には3つとも「有効化する」だけです。だからこそ、初めてのセキュリティ対応の第一歩に向いています。

次の悩み:「全部盛り」にすると高い。どう絞る?

3サービスとも従量課金(使った分だけ課金)で、オプション機能をどこまで有効にするかで金額が大きく変わります。そして初めてだと「全機能ONにしないと不安」という気持ちになりがちです。

ここで持っておきたい考え方が2つあります。

考え方1: 「守りたい資産」から逆算する

セキュリティの目的は機能を有効化することではなく、資産を守ることです。Webアプリの場合、いちばん失って困るものはたいていデータ(データベースと、ファイル置き場の中身)です。なので「データに直結する監視は入れる。そうでないものは後回し」という基準で切れます。

考え方2: 小さく始めて、実績を見てから広げる

従量課金の実額は、動かしてみないと分かりません。最初から全部盛りにすると「思ったより高い!」で頓挫しがちです。安価な基本機能だけで始めて1〜2ヶ月実測し、必要と分かったものだけ追加する方が、結果的に長続きします。セキュリティは導入して終わりではなく続けることが本体なので、「続けられる金額に収める」のは立派な設計判断です。

この2つの基準で、私たちは次のように絞りました。

GuardDuty:基本+データ資産まわりだけON

機能	判断	理由
基本の監視(操作ログ・通信ログ・DNSの分析)	✅ ON	有効化すれば自動でついてくる本体部分
S3への不審アクセス検知	✅ ON	データ資産に直結
データベースへの不審ログイン検知	✅ ON	データ資産に直結
Lambdaの不審な通信の検知	✅ ON	安価で、乗っ取りに気づける
サーバー内部の常時監視・ウイルススキャン	❌ 後回し	課金が大きく跳ねる。基本監視で実績を見てから

Inspector:使っている部品だけスキャン

対象	判断	理由
コンテナイメージ(アプリ本体)	✅ ON	最大のスキャン対象。ここが本命
Lambda関数	✅ ON	部品の欠陥を自動照合
EC2(仮想サーバー)	✅ ON	台数が少なければ課金もわずか
OS設定の詳細ベンチマーク点検	❌ 後回し	サーバー台数が少ない環境では効果が薄い

なお、EC2のスキャンだけは有効化しただけでは動きません。サーバー側にAWSの管理用エージェント(SSM Agent)が入っていて、AWSから認識されている必要があります。「ONにしたのに結果が出ない」の原因はたいていこれです。

Security Hub:チェックリストは1本だけ

Security Hubは「チェックリストの項目数×チェック回数」で課金されます。チェックリスト(セキュリティ標準)は複数用意されていますが、内容の重複がかなり多いのが実情です。

チェックリスト	判断	理由
AWS基礎セキュリティベストプラクティス(FSBP)	✅ ON	S3公開・暗号化なし等の主要な設定ミスはこれ1本で十分カバー
CISベンチマーク(セキュリティ団体CISの汎用基準)	❌ 後回し	FSBPと重複が多く、課金だけ増える
PCI DSS(クレジットカード業界基準)	❌ 不要	カード情報を扱わないなら対象外

ちなみに、Security Hubを既定設定のまま有効化するとチェックリストが勝手に複数有効化されて課金が増えるという罠があります。回避方法は後編で説明します。

見張る場所の話:東京だけだと死角がある

もう1つ、初見では絶対に気づけないポイントを共有させてください。

前提として、AWSにはリージョンという概念があります。AWSのデータセンターが置かれている地域のことで、「東京」「大阪」「米国バージニア北部」などがあります。そしてここまで紹介した3サービスは、リージョンごとに有効化するものです。東京で有効化しても、東京の中しか見張ってくれません。

問題はここからです。アプリ本体を東京リージョンに置いていても、CloudFront(コンテンツ配信)とそのWAFは、米国バージニア北部リージョン(us-east-1)に存在します。AWSの仕組み上そうなっているだけで、意識して使っていなくてもです。

東京だけを見張っていると、この領域が丸ごと死角になります。家の正面玄関にだけカメラをつけて、勝手口がノーマークの状態です。

対策はシンプルで、us-east-1でも同じ3サービスを有効化します。「見る画面が2倍になるのでは」という心配は、Security Hubのリージョン集約機能が解決してくれます。us-east-1側の検出結果を東京側の画面へ自動転送できるので、見張りは2か所、見る画面は東京の1つだけが保てます。

us-east-1側は動いているものが少ないので、追加費用はごくわずかです。

で、いくらかかるの?

小規模なWebアプリ環境(東京+us-east-1、1つのAWSアカウント)での月額の目安です。実額はログの量やスキャン対象の数で変わるため、幅で示します。

サービス	月額目安
GuardDuty(防犯カメラ)	約 $5〜30
Inspector(定期点検)	約 $3〜10
Security Hub(管理人室)	約 $3〜15
合計	約 $11〜55

月に数千円で、24時間365日の見張り体制が手に入ります。同じことを人間でやろうとしたら(そもそも不可能ですが)いくらかかるかを考えると、破格だと私は思います。

幅を潰したければ、まず検証環境で有効化して1〜2ヶ月の実額を見るのが確実です。私たちもそうしました。金額の実績があると、上司や経理への説明も一気に楽になります。

そもそも、最初は無料で試せます

ここが意外と知られていないのですが、3サービスとも無料トライアル期間があります(サービスによって15〜30日)。

さらに嬉しいことに、トライアル中は各サービスの管理画面で**「自分の環境で使い続けたら月いくらになるか」の推定額が確認できます。上の表はあくまで一般的な目安ですが、これはあなたの環境の実データに基づいた数字**です。

つまり、お金を払う前に実額の見当がつけられます。「料金が読めないから提案しづらい」という状況なら、まずトライアルで数字を作ってしまうのが早いです。

導入した後の話

有効化して終わり、ではありません。むしろここからが本番です。初めての人が確実にぶつかる3つの場面を、先回りしておきます。

場面1: 最初に大量の指摘が出て、心が折れる

既存の環境でSecurity Hubを有効化すると、初回のチェックで数十〜数百件の「不合格」が一気に出ます。ほぼ確実に出ます。

これは「あなたの環境がひどい」という意味ではありません。今まで一度も点検していなかった家を、初めて専門業者に点検してもらったというだけです。新築でも初回点検では指摘は出ます。

ここでやりがちな失敗が2つあります。

• 全部直そうとして力尽きる
• 数の多さに圧倒されて、二度と画面を開かなくなる

どちらも避けるために、見る前に次の3つを決めておくことをお勧めします。

1. 重要度で切る
   検出結果には「重大 / 高 / 中 / 低」の重要度が付いています。対応するのは「重大」と「高」だけ。「中」以下は当面見なくてよいと最初に決めてしまう。これだけで対象が一気に減ります。
2. 対象外は消してよい
   「うちでは使っていない機能の指摘」「意図してそう設定しているもの」は、抑制(Suppressed)という機能で一覧から消せます。ごまかしではなく、「確認済み・対応不要と判断した」という記録を残す正式な手段です。遠慮なく使ってください。
3. 件数ゼロを目指さない
   これがいちばん大事です。指摘を0件にすることは目的ではありません。目的は「新しく増えた重大な指摘に、すぐ気づけること」です。

3つ目を補足します。件数を0にするより、「うちは平常時だいたい◯件」を把握しておいて、増えたときに気づけるほうが実務では価値があります。0を目指すと必ず途中で息切れしますが、「増分を見る」なら何年でも続けられます。

場面2: 検知が出たけど、何をすればいいか分からない

先ほど「気づいた後に対応するのは人間」と書きました。その人間が何をするのか、型を持っておくと慌てません。次の4段階です。

1. 読む — 検出結果には「何が・どのリソースで・なぜ怪しいと判断されたか」が書かれています。まずそれを読む
2. 切り分ける — 心当たりを確認する。自分たちの作業や、いつものバッチ処理ではないか。「怪しく見えるが実は正常」はかなり多いので、いきなり事故と決めつけない
3. 止める — 本物っぽいなら、まず被害の拡大を止める。疑わしいアクセスキーを無効化する、不審なサーバーを隔離する、といった応急処置です。原因究明は後でいい
4. 直す — 落ち着いてから根本原因を潰す。鍵が漏れたなら漏れた経路を、設定ミスなら設定を

この記事の範囲は「気づける状態を作る」までですが、2番の「切り分ける」を誰がやるのかだけは、導入前にチームで決めておいてください。検知は必ず出ます。そのとき「これ、誰が見るんだっけ?」から始まると、それだけで半日溶けます。

場面3: 通知を作りたくなる(が、最初は作らない)

導入すると「検知したらSlackやメールに通知したい」と思うはずですが、最初はあえて作らないことをお勧めします。

理由は、導入直後は「どんな検出が、どれくらいの量、どれくらいのノイズ混じりで出てくるか」が誰にも分からないからです。この状態で通知をつなぐと、通知チャンネルがノイズであふれ、全員が既読スルーするようになり、本当に大事な検知まで埋もれます。オオカミ少年化した通知は、無いより悪いです。

なので最初の運用はこれだけです。

週に1回、決まった曜日に、東京リージョンのSecurity Hubの画面を見る。

まずはこれで十分です。数週間も続けると「うちの環境の平常運転」が肌感覚で分かってきます。そのうえで「これが出たら即知りたい」という検知だけを絞って通知化すれば、鳴った瞬間に全員が反応する、信頼できるアラートになります。

前編のまとめ

長くなったので、考え方の骨子だけ再掲します。

1. デプロイ直後のAWSは「鍵はかけたが、誰も見張っていない家」。足りないのは戸締まりではなく見張り
2. 脅威は3種類に分類できる: ①攻撃(泥棒) ②脆弱性(建材のリコール) ③設定ミス(窓の閉め忘れ)。どれも人手では見張れない
3. 3分類にはAWSサービスが1対1で対応する: GuardDuty(防犯カメラ)/ Inspector(定期点検)/ Security Hub(管理人室)。報告はSecurity Hubに集まるので見る画面は1つ
4. 全部盛りにしない。「守りたい資産(データ)に直結するか」で絞り、小さく始めて実測してから広げる
5. us-east-1が死角になりがち。両リージョンで有効化し、集約で「見る画面1つ」を保つ
6. 料金が読めないなら、無料トライアルで自分の環境の推定額を作ってから判断すればいい
7. 有効化直後に大量の指摘が出るのは正常。「重大・高だけ対応」「対象外は抑制」「件数ゼロは目指さない」を先に決めておく
8. 検知が出たときは「読む → 切り分ける → 止める → 直す」。誰が切り分けるかだけは導入前に決めておく
9. 通知は最初は作らず、週1回画面を見る運用から。傾向を掴んでから絞って通知化する